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

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") ??

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

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 }

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

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  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

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

 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

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

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

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

Enterprise “Roles” AD Web Expense Application Supply Application DataBase Application Use AD Groups to populate Application level Roles Employee (AD Group) 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  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) x?FamilyID=e487f885-f0c7-436a-a a25bad7&DisplayLang=en x?FamilyID=e487f885-f0c7-436a-a a25bad7&DisplayLang=en  How to use AzMan with ASP.NET =/library/en-us/dnpag2/html/paght asp =/library/en-us/dnpag2/html/paght asp  How to use AzMan with WSE /AzManandWSE30/default.aspx 1/AzManandWSE30/default.aspx

Ihr Potenzial. Unser Antrieb.