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

<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 - 24.11.2005 im Kempinski Airport Hotel, München

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 - 24.11.2005 im Kempinski Airport Hotel, München

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 - 24.11.2005 im Kempinski Airport Hotel, München

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 - 24.11.2005 im Kempinski Airport Hotel, München

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

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

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

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

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

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

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

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

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:

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

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.

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

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

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

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

Fragen und Antworten

Mehr Informationen W2K3 Admin Tools Pack (works also on XP) http://www.microsoft.com/downloads/details.aspx?FamilyID=e487f885-f0c7-436a-a392-25793a25bad7&DisplayLang=en How to use AzMan with ASP.NET 2.0 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/paght000019.asp How to use AzMan with WSE 3.0 http://msdn.microsoft.com/msdnmag/issues/05/11/AzManandWSE30/default.aspx

Ihr Potenzial. Unser Antrieb.