Identity for.NET Applications: A Technology Overview David Chappell Chappell & Associates

Session Objectives Provide a basic understanding of Microsoft’s identity technologies for application developers Give a clear sense of how they fit together today and when to use each one Explain why claims-based applications matter

Identity Basics Identity Within a Windows Forest Identity Between a Forest and Other Identity Scopes Identity for Internet Applications Synchronizing Identity Information Agenda

Identity Basics

What is Identity? An identity is a set of information about some entity, such as a user Users often have multiple identities An application can use this information in various ways, such as: Authentication: Does this information really describe the user who presented it? Authorization: What does the application let this user do? Personalization: How does the application interact with this user?

Token Claim 1... Claim 2 Claim 3 Claim n A token is a set of bytes that expresses information about an identity This information consists of one or more claims Each claim contains some information about the entity to which this token applies How an identity is represented on the wire Name Example Claims GroupAge

Kerberos ticket Commonly used for applications within a Windows forest Includes a user’s name and group identifiers Fixed format; extensions are difficult Username/password Commonly used for Internet applications Security Assertion Markup Language (SAML) token Can be used for applications within a Windows forest and Internet applications Open XML-based format; can contain any claims

Identity Providers and Token Sources An identity provider is an authority that makes claims about an entity Common identity providers today: On your company’s network: Your employer On the Internet: Most often, you An identity provider can rely on a token source It’s software that actually issues tokens

Application Client Identity Provider 1) Acquire token TokenToken 2) Send token TokenToken Token Source

Domain-based applications: Accept only a single token format with a fixed set of claims Example: A Windows application that accepts only Kerberos tickets The most common approach today Claims-based applications: Can potentially accept multiple token formats with varying sets of claims Example: A Windows application that accepts SAML tokens containing various claims The direction for the future

Identity within a Windows Forest

Identity In a Single Identity Scope A Windows forest defines an identity scope The forest can be viewed as having a single identity provider, e.g., the organization the forest belongs to Tokens issued within a forest can be used with any application in the forest

Token Sources Within a Forest For domain-based applications: Active Directory (AD) Domain Services Formerly called just Active Directory Token: Kerberos ticket For claims-based applications: Active Directory Federation Services (ADFS) Token: SAML token

3) Extract claims from token and authenticate Windows Domain ApplicationClient 4) (Optional) Use claims to look up information about user AD Domain Services Windows 1) Acquire token KerberosTicket 2) Send token KerberosTicket Token Source

Focused on supporting claims-based applications, allowing: The user to supply the application directly with the information it needs as claims Accepting identities defined in another scope: identity federation A standard part of Windows Server 2003 R2 And Windows Server 2008 ADFS currently supports only browser clients ADFS 2.0 is scheduled to support other options

AD Domain Services 1) Access application and get redirected to ADFS server Windows Domain Application Windows Server 2003 R2 2) Authenticate and request token for application Kerberos Ticket ADFS Server Token Source 4) Send token to application SAML Token ADFS Acquiring and using a token in the same forest Web Browser 3) Receive token for application SAML Token ADFS Agent

NT Token applications Remain unaware that ADFS is used The ADFS agent makes everything look normal Existing applications can work unchanged with ADFS Claims-aware applications Written to use specific claims Use an ADFS-provided namespace to access claims in the SAML token Require configuring the ADFS Account Server to insert those claims in the token

A claim can identify a user A claim can convey group or role membership A claim can convey personalization information Such as the user’s display name A claim can grant the right to do something Such as access particular information or invoke specific methods A claim can constrain the right to do something Such as indicating the user’s purchasing limit

Identity between a Forest and Other Identity Scopes

Identity Across Identity Scopes Describing the problem A user in one Windows forest must access a Web application in another Windows forest A user in a non-Windows scope must access a Web application in a Windows forest (or vice-versa)

Identity Across Identity Scopes Some possible solutions One option: duplicate accounts Requires separate login, extra administration A better approach: identity federation One scope accepts identities provided by the other No duplicate accounts Single sign-on for users ADFS allows identity federation for Web applications The ADFS protocol exchanges are defined by WS-Federation, which is also supported by IBM, Oracle, and others

1) Access application and get redirected to resource server Application ADFS Agent Windows Server 2003 R2 ADFS Resource Server Token Source Account Domain (Windows or Other) Resource Domain (Windows ) 3) Authenticate and request token for resource server Token WS-Federation- Compatible Account Server (ADFS or Other) Token Source ADFS Acquiring and using a token across scopes (1) 2) Request SAML token for application and get redirected to account server SAML Token for Resource Server 4) Receive token for resource server Web Browser

ADFS Agent Windows Server 2003 R2 ADFS Resource Server Token Source WS-Federation- Compatible Account Server (ADFS or Other) Account Domain (Windows or Other ) Resource Domain (Windows ) Token Source 6) Receive token for application SAML Token for Application 7) Send token to application SAML Token for Application 5) Request token for application SAML Token for Resource Server ADFS Acquiring and using a token across scopes (2) Application

Identity for Internet Applications

Identity on the Internet Most Web applications use Username/Password today Pros: Easy to implement Easy for users to access apps from different machines Cons: Easy to steal and reuse: phishing

Identity on the Internet A claims-based alternative Windows CardSpace allows a claims-based view of identity It offers two choices: Using identities issued by CardSpace’s self-issued provider Uses SAML tokens with a standard set of claims Provides a more secure alternative to username/password Using identities issued by a managed identity provider Can use any kind of token with any claims Allows any organization to act as an identity provider Each application indicates the tokens and identity providers it will work with

Internet 3) Extract claims (username and password) from token 2) Send username/ password token Token Windows Windows Domain 4) Look up user, authenticate, and (optionally) find other information Application Identity Provider 1) Provide username and password Client

Identity Provider Application Windows Windows Domain Internet 2) Send CardSpace self-issued token SAML Token 3) Extract claims (PPID, etc.) from token 4) Look up user and find other information Store 1) Acquire CardSpace self- issued token SAML Token Windows CardSpace Self- Issued Provider Token Source Client

Application Windows Windows Domain Internet 2) Send token TokenToken Client 3) Extract claims from token 4) Look up user and find other information Store 1) Acquire tokenTokenToken Managed Identity Provider 1... Managed Identity Provider N Security Token Service (STS) Security Token Service (STS)

CardSpace is first applied on the Internet But the technology isn’t limited to this It can also potentially be used: Within a single identity scope, e.g., a Windows forest Across scopes, e.g., for federation To help do this, ADFS 2.0 will include a managed identity provider CardSpace allows a user-centric approach to identity

Synchronizing Identity Information

Mapping Between Identity Stores Identity information is often stored in several different places Keeping this information synchronized is sometimes required Identity Lifecycle Manager (ILM) 2007 can do this It’s the successor to Microsoft Identity Integration Server (MIIS) 2003 It can be used within or between organizations

AD Domain Services Identity Store AD Lightweight Directory Services IdentityStore Novell eDirectory IdentityStore IBM Mainframe Application IdentityStore SAP IdentityStore Microsoft Exchange Server IdentityStore SQL Server IdentityStore Identity Lifecycle Manager 2007 If … Then … Rules Actions

Architect for identity Be wary of domain-based applications Applications that accept only a Kerberos ticket or only a username/password can be problematic When possible, create claims-based applications using: ADFS for Windows forests and for cross-scope identity federation Windows CardSpace for the Internet Consider ILM for synchronizing identity data

About the Speaker David Chappell is Principal of Chappell & Associates ( in San Francisco, California. Through his speaking, writing, and consulting, he helps IT professionals understand, use, and make better decisions about enterprise software. David has been the keynote speaker for dozens of conferences and events in the U.S., Europe, Asia, Latin America, and Australia. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries. David’s books have been published in ten languages and used regularly in courses at MIT, ETH Zurich, and many other universities. He is Series Editor for Addison-Wesley’s award-winning Independent Technology Guides, and he has been a regular columnist for several publications. In his consulting practice, David has helped clients such as Hewlett- Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business plans. David’s comments have appeared in The New York Times, CNN.com, and various other publications. Earlier in his career, he wrote software for supercomputers, chaired a U.S. national standardization working group, and played keyboards with the Peabody-award-winning Children’s Radio Theater. David holds a B.S. in Economics and an M.S. in Computer Science, both from the University of Wisconsin-Madison.