Transcript Developing Active Directory Based Application

10 – 12 APRIL 2005 Riyadh, Saudi Arabia
Developing Active Directory
Based Application
Abdellatif Tarhine
Microsoft Regional Director for North Africa
[email protected]
Session Objectives
Approaches for Authentication:
These approaches focus on determining which authentication method is
appropriate. Windows Integrated Authentication and/or Forms-Based
Authentication.
Approaches for Passing Identity Information between
Application Tiers:
These approaches focus on determining which of the three identity flow
models are appropriate, or whether they can be combined.
Approaches for Authorization:
Compare and contrast ASP.NET Roles and Authorization Manager for RBAC
(Role Based Access Control)
Key Takeaways
Use the Windows Server Infrastructure – AD & ADAM,
AzMan, Windows Integrated Security Services
Easier to manage because they don't introduce additional user
identity stores
More secure as enterprise security services are developed,
designed and managed with much more thoroughness than
one-off application developer-designed security mechanisms
Easier to integrate with other software systems since it is easier
to find a common ground for security interaction between
applications
Agenda
Introduction
Identity Flow & Authentication
Authorization
Auditing
Summary & Call to Action
Index: Fundamental Concepts & Backup
Slides
Introduction
Business Challenges & Benefits
Introduction
The Business Challenges
Rapidly develop line-of-business (LOB) applications
Leverage Active Directory infrastructure
Achieve greater security
Capitalize on a consistent authorization policy models &
data
Effectively use existing provisioning mechanisms
Provide secure access for different types of users
Meet the authentication, authorization, and audit
requirements of new industry & government regulations
Introduction
The Business Benefits
Reduced application development costs and
faster time to market
More robust applications
Fewer vulnerabilities
Reuse existing mechanisms and solutions.
More secure access control
Compliance with regulatory requirements
Identity Flow & Authentication
Approaches & Flow Models
Identity Flow Models
Impersonation/Delegation
Trusted Subsystem
Credential Mapping
Combining Models
Identity Flow Models
Impersonation/Delegation
Network Resource or Service can “flow” Identity from one point to
another
Delegation of the user context or credentials
Simple Example: Passing the plaintext user password from app
component to app component or to a network resource
Note: Delegation is often described in the Context of a particular Authentication Protocol
Identity Flow Models
Kerberos Protocol Delegation
Advantages
Unconstrained Delegation
Constrained Delegation (New in
WS2K3) – A2D2
Protocol Transition (Internet)
Resource is always
accessed by user
System Level Access
Auditing
Disadvantages
No connection Pooling
Not all Tiers support
Impersonation/
Delegation model
Mainframe
Other Non-Microsoft
Server
Identity Flow Models
Kerberos Protocol Delegation
Operating System
Delegation
Windows NT with IIS 4.0
No
Windows 2000 with IIS 5.0
Yes
The operating system can delegate, but cannot constrain the delegation to
certain services.
You can use unconstrained delegation from another computer running Windows
2000 Professional or constrained delegation from a computer running Windows
Server 2003.
Windows Server 2003 w/ IIS 6.0
Yes
The operating system fully supports both unconstrained and constrained
delegation.
Application
Kerberos Protocol Support
Exchange Server 5.5 or earlier
No
Exchange Server 2000 or later
Yes
SQL Server™ 7.0 or earlier
No
SQL Server 2000 or later
Yes
NTFS on Windows 2000 or later
Yes
SAP R3
Yes
Identity Flow Models
Trusted Subsystem
All Authentication &
Authorization occurs on the
web server
Typically used with RBAC
ASP.NET Roles
AzMan
Advantages
Simplified permissions management
Connection Pooling
Access only through app – not
tools/APIs
Disadvantages
Service Account must be wellprotected
No support for system-level audits on
resources
Identity Flow Models
Credential Mapping
Indirect integration
between AD & other IdM
Stores
MS Products with
ESSO:
Advantages
Heterogeneous Security Models
Deferred Credential Use (Asynch) –
Msg Queues, Service Brokers…
Disadvantages
BTS 2004
Storage of User Credentials Risky
SPS 2003
Password Synchronization
HIS 2004
Identity Flow Models
Identity Flow & Authorization Model Considerations
Trusted
Subsystem
Model
Requirement
Delegation
Model
Credential
Mapping Model
Highly scalable, high
transaction rate throughput
required.
l

m
Granular audit logs desirable
on different target systems.
m
l

Sensitive data protected by
granular ACLs.
m
l


m
l
Cross-platform interoperability.
l
Meets requirement
m
Does not meet requirement

May meet requirement – need to confirm for your specific application.
Identity Flow Models
Combining Models
With Web servers & app servers on separate physical tiers, a developer could
choose to use the Delegation Model between Web servers and the app servers. The
application servers could then:
Use Delegation Model to access Kerberos v.5 enabled SAP
R/3 App Server
Use Delegation to access MS SQL Server
Use Trusted Subsystem to Participate in Services providing
high transactional throughput
Use Credential Mapping to access mainframe resources
using RACF user accounts
Note: The credential mapping would have failed if the architect had chosen the Trusted Subsystem Model instead of the
Delegation Model between the Web server(s) and the application server(s).
Authorization
ASP.NET Roles & Authorization Manager
Authorization
Mechanisms
Access Control List Model
NT Private Object Security (POS) APIs – old school
Authz APIs – new school (Windows XP/WS2K3)
Resource Managers: Well-Defined, Persistent Objects
Role-Based Access Control Model
Maps user job roles to app permissions
Little need to change roles once established
Manage Membership not Permissions on Objects
RBAC Implementation:
COM+ Roles
ASP.NET Roles
URL Authorization
Role-Based Security
Windows Authorization Manager
URL Authorization
Role-Based Security
ASP.NET Roles
The built-in capabilities of ASP.NET provide
two ways of implementing role-based
authorization:
URL Authorization
Role-Based Security
ASP.NET Roles
URL Authorization
Add <Authorization> header to Web.config, for example:
<authorization>
<allow users="DomainName\Bob" />
<allow users="DomainName\Mary" />
<deny users="*" />
</authorization>
‫قف‬
ASP.NET URL authorization also allows for access based on role, for
example:
<authorization>
<allow roles="Administrator" />
<deny users="*" />
</authorization>
Note: Although ASP.NET URL authorization provides basic role-based access at the URL level, the manual configuration it requires through
Web.config files makes it unsuitable for an enterprise environment.
ASP.NET Roles
Role-Based Security
ASP.NET Applications can use IsInRole Method (System.Security.Principle,
for example:
If (User.IsInRole("BUILTIN\\Administrators"))
ExecutePrivilegedOperation();
EndIf
Roles are derived directly from server local groups or AD groups
Uses Authorization Information (Windows Groups) from the Windows
Impersonation Token
Token created automatically by IIS-integrated Authentication Mechanisms
Manually created for Forms-based apps
ASP.NET Roles
Forms-Based Authentication
Assigning Roles in Forms-based authenticated user:
public void Application_AuthenticateRequest(Object s, EventArgs e)
{
if (HttpContext.Current.User != null)
{
if (HttpContext.Current.User.Identity.AuthenticationType == "Forms" )
{
System.Web.Security.FormsIdentity id = HttpContext.Current.User.Identity;
String[ ] myRoles = new String[3];
myRoles[0]= "managers";
myRoles[1]= "testers";
myRoles[2]= "developers";
‫قف‬
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id,myRoles);
}
}
}
If new role (group) is added code must be changed
Other Authorization Methods Abstract roles from Application – isolating policy changes
Authorization Manager
AzMan Advantages
Introduced in Windows Server 2003 – Also available for Windows Server 2000
Centralized authorization policy for multiple applications
The ability to create security groups outside of Active Directory and
managed by the application administrator
The ability to create groups based on the result of an LDAP query
Relies on a Policy Store for one or more apps
Hierarchical
Delegated Admin (AD & ADAM only)
XML Store – not recommended for Enterprise Apps
Authorized users “Must” have an actual account on the web server or
user account in AD or ADAM
RBAC Management
XML
Policy Store
Storage in AD, ADAM, XML
Policy Store
Deployment
Role
Permissions needed to
do a job
Buyer
Acct Rep
Task
Work units that make sense
Check
Status
Cancel
Report
Submit
Report
to administrators
developer writes dedicated
code for.
Approve
Deny
Payment
Change
Approver
Design
Operation
Application action that
Approve
Reject
Report
Auditor
Web
Operation
Database
Operation
Payment
System
Operation
Directory
Operation
Role Assignments
Web Ordering
Application
Role Definitions
Buyer
Acct Rep
Auditor
Role Assignment
Buyer: email = *@ADatum.com
Role Assignment
Acct Rep: Group = Dept01Manager
Role Assignment
Auditor: (Group = TreyAuditor) && (Status = Active)
Authorization Manager
Advantages
3 Key Mechanisms for user Role Assignments:
Membership in AD or Local Server, or AzMan Groups
LDAP Query Groups
BizRules
Centrally Managed across the organization
without managing Web.config files or changing
application code
IIS 6.0 URL Authorization
Advantages
Provides same functionality as ASP.NET URL
Authorization
Based on Windows Authorization Manager Policy
NOT individual application policy
Great Option for Web Services or Static Content
(htm pages)
More Flexible – not constrained to security group
membership
Authorization Manager
Futures
Long-term RBAC Plans
Enhance AzMan
Add features
Address some deployment issues
Migrate AzMan applications
Server SP1
ADFS integration
ADAM principal integration
Perf and Scalability improvements
Whidbey
ASP.Net Role Manager integration
Longhorn
Common asks, more queries, UI flexibility, better logging and
debugging support, Ldap query ehancement, simpler access check.
Security Auditing
Summary
Security Auditing
Authorization & Authentication Systems
automatically create logs
Create App Specific Audit Trails when not using
AzMan & CredMan
Monitor the Security Event Log
Use MOM & EIF
*For detailed information, see the "Logging Application Block" on MSDN at:
http://msdn.microsoft.com/library/en-us/dnpag/html/Logging.asp.
Summary & Call to Action
Use the Windows Server Infrastructure – AD & ADAM,
AzMan, Windows Integrated Security Services
Easier to manage because they don't introduce additional user
identity stores
More secure as enterprise security services are developed,
designed and managed with much more thoroughness than
one-off application developer-designed security mechanisms
Easier to integrate with other software systems since it is easier
to find a common ground for security interaction between
applications
Additional Resources
The Microsoft Identity & Access Management Series
www.microsoft.com/technet/security/topics/identity/idmanage/default.mspx
Solution Series White Papers
Part I – The Foundation for Identity and Access Management
Part II – Identity Life-Cycle Management
Part III – Access Management and Single Sign On
Complementary Solutions from Microsoft
Microsoft Systems Architecture - Microsoft Solutions for Security
Solution Guide for Windows Security and Directory Services for UNIX
Complementary Solutions from Microsoft Partners
Oblix/Microsoft Identity and Access Management Solution Accelerator
OpenNetwork/Microsoft Identity and Access Management Solution Accelerator
Netegrity/Microsoft Identity and Access Management Solution Accelerator
Additional Resources
Microsoft Identity and Access Management Series
Developing Identity-Aware ASP.NET
Applications
New Addition to the series
Implementation & Testing
Deployment & Operations Considerations
Location of the paper: www.microsoft.com\idm\
Additional Resources
More Background Information
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure
Communication (Nov 2002)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpmsdn.asp
Part I, Security Models
Part II, Application Scenarios
Part III, Securing the Tiers
Writing Secure Code, 2nd Edition (Dec 2002)
http://www.microsoft.com/mspress/books/5957.asp
Part I, Contemporary Security
Part II, Secure Coding Techniques
Part III, Even More Secure Coding Techniques
Part IV, Special Topics
Improving Web Application Security: Threats and Countermeasures (June 2003)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpmsdn.asp
Part I, Introduction to Threats and Countermeasures
Part II, Designing Secure Web Applications
Part III, Building Secure Web Applications
Part IV, Securing Your Network, Host and Application
Part V: Assessing Your Security
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.