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

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?

Tokens 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

Tokens 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 XML-based; can contain any claims Example formats

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 Acquiring and Using a Token How the parts fit together

Categorizing Applications By how they work with identity 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 Application Client AD Domain Services AD Domain Services Acquring and using a token Windows Token Source

ADFS Basics Supports 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 Windows Domain Application Windows Server 2003 R2 ADFS Acquiring and using a token in the same forest Web Browser

How Applications Use ADFS Two options 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

How Applications Can Use Claims Some examples 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

Application Windows Server 2003 R2 Account Domain (Windows or Other) Resource Domain (Windows ) ADFS Acquiring and using a token across scopes (1) Web Browser

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 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 offers two choices: Allows 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 Allows 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 CardSpace can also be used on intranets

Internet Windows Username/Password Acquiring and using a token Windows Domain Application 1) Provide username and password Client

Windows CardSpace Using a token from a self-issued provider Application Windows Windows Domain Internet Client

Windows CardSpace Identity selector screen

Windows CardSpace Using a token from a managed provider Application Windows Windows Domain Internet Client

Windows CardSpace Looking ahead CardSpace is first applied on the Internet But the technology isn’t limited to this ADFS 2.0 will include an STS Managed identity providers can also be used: Within a single identity scope, e.g., a Windows forest Across scopes, e.g., for federation Expect CardSpace to be applied more broadly It 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

Identity Lifecycle Manager 2007 An illustration

Conclusion What to do next 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

For Further Reading Digital Identity for .NET Applications: A Technology Overview http://msdn2.microsoft.com/en-us/library/bb882216.aspx

About the Speaker David Chappell is Principal of Chappell & Associates (www.davidchappell.com) 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.