1. Autorisierung und rollenbasierte Sicherheit in .NET Anwendungen
Jürgen Pfeifer
Senior Architect Evangelist
Developer & Platform Strategy Group
Microsoft Deutschland GmbH

2. <Vortragstitel>
Role-Based Security
Code runs on behalf of a user
Users have roles
Declarative and imperative Checks
Principals and Identities
IsInRole("Administrator") ??
Identity: Jane
Roles: Administrator,
Developer
III. Architects Forum im Kempinski Airport Hotel, München

3. Identities and Principals
<Vortragstitel>
Identities and Principals
An identity contains information about a user, such as the user’s logon name. Abstracted by the IIdentity Interface.
A principal contains role information about a user or computer. Abstracted by the IPrincipal Interface.
The .NET Framework provides:
WindowsIdentity and WindowsPrincipal objects
FormsIdentity and PassportIdentity for ASP.NET
GenericIdentity and GenericPrincipal objects
Custom and 3rd-Party implementation
e.g. an Implementation by IBM to derive Identities and Principals from the Tivoli Access Manager
An identity contains information about the user’s identity, such as their logon name and whether the user is authenticated.
A principal contains information about the role membership for a user or computer.
The .NET Framework implements two major types of identities and principals.
WindowsIdentity and WindowsPrincipal objects provide information about the Windows credentials for a user.
GenericIdentity and GenericPrincipal objects enable the developer to implement their own authentication technique.
The following slides show how to create Windows and Generic principals and identities, and then demonstrates how to use them to make role-based security checks.
III. Architects Forum im Kempinski Airport Hotel, München

4. Performing Security Checks
<Vortragstitel>
Performing Security Checks
Use Identity and Principal members in code
For example, using the Name property of the Identity object to check the user’s logon name
For example, using the IsInRole method of the Principal object to check role membership
if (String.Compare(myPrin.Identity.Name, "DOMAIN\\Fred",
true)==0) {
// Perform some action }
Now that you have seen how to create identities and principals, you can use them to perform security checks in your code. The slide demonstrates two examples.
The first code example performs a case-insensitive string comparison of the current identity’s Name property and a hard-coded string.
The second code example uses the IsInRole method to check role membership. In this example, the code checks whether the principal is a member of the built in Administrators group.
if (myPrin.IsInRole("BUILTIN\\Administrators")) {
// Perform some action }
III. Architects Forum im Kempinski Airport Hotel, München

5. Imperative and Declarative Security Checks
<Vortragstitel>
Imperative and Declarative Security Checks
Use permissions to make role-based security checks
Imperative checks
PrincipalPermission prinPerm = new PrincipalPermission(null, “Teller”, true);
try {
prinPerm.Demand(); //Does the above match the active principal? }
You can also use imperative and declarative approaches for role-based security checks.
The first code sample on the slide uses an imperative security check to determine whether the active principal object's permissions match the permissions of the newly created prinPerm object. The call to the Demand method will throw a security exception if the permissions do not match. This approach is useful if you want to secure specific actions within your code.
The second sample on the slide uses declarative security. The attribute shown can be applied to a class or an individual method, so that a security check is performed when the class or method is used. Although the same types of check can be performed as with the imperative approach, the declarative process makes it easier to review the required permissions for a class or method. However, because the checks apply only to classes or methods, this approach is slightly less flexible than imperative checking.
Declarative checks
[PrincipalPermission(SecurityAction.Demand, Role="Teller", Authenticated=true)]
III. Architects Forum im Kempinski Airport Hotel, München

6. Application Authorization Needs
Resource Managers
Well-defined, Persistent Resources.
Filesystem, Registry, Directory
Gatekeepers
Controls access to other applications
e.g. Web Server
Line of Business Applications
Resources aren’t well defined or persistent
Access = operations, processes, workflows
E.g. Submit expense

7. Impersonation Vs Trusted Subsystem
Get client token, impersonate, access resources
Audit close to data
Access Limited to connected user
ACLs on Back end need to be maintained
Connection pooling is difficult
User’s can potentially access back end data out of band
Trusted Subsystem
Service Authorizes client requests, performs actions in service context
Minimizes back end ACL management (grant Service needed access)
Allows connection pooling.
Users can’t directly touch back end data
Audits must be correlated
Service account password must be maintained

8. Goals for Authorization Manager
Role-Based framework for LOB Apps
Access control defined by job need
Rights maintained at Roles not objects
Better Manageability
Task concept: Grouping permissions
User centric: What can Employees do?
Simple: No ACL-inheritance
More Natural for Development
ACLs can be unnatural for some apps
Simple, scriptable interfaces

9. Development Goals Simple & Natural Role-based development
Define Operations, Tasks, Roles, Biz rules
Provide flexible application scoped groups
Application admins don’t need domain admin to create groups
Platform services do the hard work
Policy storage, Common UI
Built-in caching, Late-binding support,
Auditing

10. Administration Goals User provisioning, not resource protection
Assigning groups and users to roles (not objects)
Manage Roles and Scopes
Not objects and hierarchies.
Delegation
Common Administration Easy
Hide complexity of operations
Defining roles, tasks rare design)
Maintaining Roles & Groups

11. Authorization Manager
Role
What someone may need to be able to do as part of their job.
Task
Work-Units that make sense to administrators
Biz Rule (Authorization Script)
Script to Dynamically modify Access decision
Scope
Collection of resources with common policy.
Defines where one or more roles may apply
Groups
Application Specific, Late-bound, Flexible

12. AzAuthorizationStore
Authorization Manager AD
XML
AzAuthorizationStore
AzApplication
AzApplicationGroup
Declarative,
Query
AzApplicationGroup
AzOperation
AzTask
BizRule
AzRole
AccessCheck
AzClientContext
AzScope
(Roles, Tasks, Groups)

13. Role={Tasks}, Task={Operations}
Web Expense
Application
Administrator
Approver
Submitter
Change
Approver
Approve
Deny
Payment
Reject
Report
Submit
Cancel
Check
Status
Web
Operation
Database
Operation
Payment
System
Operation
Directory
Operation

14. Role Definitions & Assignments, Scopes
Web Expense
Application
Role Definitions
Submitter
Approver
Administrator
Submitter: Employees
Scope: Default
Web Expense
Role Assignments:
Approver: QueryGroup_D1Mgrs
Administrator: Jane, Lizzy
Dept 01
Role Assignments:
Scope: Dept 01
Approver: ADGroup_D2Mgrs
Administrator: Jane, Charlie
Scope: Dept 02
Dept 02
Role Assignments:

15. Enterprise “Roles” Use AD Groups to populate Application level Roles
Employee
(AD Group)
Web Expense
Application
Supply
Application
DataBase
Application
Employee
Employee
Employee

16. Development Model Application Development
Implement operations, Tasks, BizRule scripts
Install - Declare Policy definition
Operations, Tasks (w/ BizRules), Some Roles
Runtime
AzInitializeAdminMgr,AzInitializeApplication
On Client Connect:
AzInitializeContext (from NT token or UserName or Sid)
Render UI: GetRolesForUser
On Operation Request
AzClientContext.AccessCheck(Scope, Operation Operation Data)
Biz Rules are automatically executed.

17. Role-Based Common UI Multiple Applications Application Groups
Static, LDAP Query
Store-level (Global to Apps in Store )
Assign Store-level Groups to Roles
Developer Mode
Create Apps/Operations

18. New For Longhorn SQL Storage Support Expanded LDAP Query support
Provide SQL storage mechanism
Popular request of departmental apps
Expanded LDAP Query support
Queries on any DN (not just users)
Expanded BizRule support
Support group membership based on rules

19. New For Longhorn UI object picker customization
Add support for Apps to provide ADAM object picker
Enhanced / Debugging Logging
More debugging API
Improve V1 logging support
Log more events, easier to use

20. Longhorn Improvements
Simplify developer experience
Role-definition object
Simplify Biz Rule usage
Performance improvements
Optimized interfaces for managed application
Store creation
Application initialization

21. Fragen und Antworten

22. Mehr Informationen
W2K3 Admin Tools Pack (works also on XP)
How to use AzMan with ASP.NET 2.0
How to use AzMan with WSE 3.0

23. Ihr Potenzial. Unser Antrieb.