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

2. Role-Based Security  Code runs on behalf of a user  Users have roles  Declarative and imperative Checks  Principals and Identities Identity: Jane Roles: Administrator, Developer IsInRole("Administrator") ??

3. 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 3 rd -Party implementation  e.g. an Implementation by IBM to derive Identities and Principals from the Tivoli Access Manager

4. 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 } if (myPrin.IsInRole("BUILTIN\\Administrators")) { // Perform some action }

5. 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? } [PrincipalPermission(SecurityAction.Demand, Role="Teller", Authenticated=true)]  Declarative checks

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  Impersonation  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.  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 Authorization Manager

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

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

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

15. Enterprise “Roles” AD Web Expense Application Supply Application DataBase Application Use AD Groups to populate Application level Roles Employee (AD Group) 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  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) http://www.microsoft.com/downloads/details.asp x?FamilyID=e487f885-f0c7-436a-a392- 25793a25bad7&DisplayLang=en http://www.microsoft.com/downloads/details.asp x?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 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/1 1/AzManandWSE30/default.aspx http://msdn.microsoft.com/msdnmag/issues/05/1 1/AzManandWSE30/default.aspx

23. Ihr Potenzial. Unser Antrieb.