360 likes | 552 Views
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
E N D
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
Agenda Identity Basics Identity Within a Windows Forest Identity Between a Forest and Other Identity Scopes Identity for Internet Applications Synchronizing Identity Information
What is Identity? • An identityis 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 ToTokenskens How an identity is represented on the wire • 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 Token Example Claims Claim 1 Name Claim 2 Group Claim 3 . . . Age Claim n
Tokens • Example formats TTokens 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
Acquiring and Using a TokenHow the parts fit together Identity Provider Token Source 1) Acquire token 3) Use claims in token Token Client Application Token 2) Send token
Categorizing ApplicationsBy 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-basedapplications: • 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 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
AD Domain ServicesAcquring and using a token Windows Domain AD Domain Services Token Source 1) Acquire token 4) (Optional) Use claims to look up information about user Kerberos Ticket 2) Send token Client Application Kerberos Ticket 3) Extract claims from token and authenticate Windows
ADFSBasics • Focused on supporting claims-basedapplications, 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
ADFSAcquiring and using a token in the same forest Windows Domain AD Domain Services Token Source ADFS Server SAML Token SAML Token Kerberos Ticket 5) Use claims in token 3) Receive token for application 2) Authenticate and request token for application 4) Send token to application ADFS Agent Application Web Browser Windows Server 2003 R2 1) Access application and get redirected to ADFS server
How Applications Use ADFSTwo 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 ClaimsSome 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 Across Identity ScopesDescribing 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 ScopesSome 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
ADFSAcquiring and using a token across scopes (1) Account Domain (Windows or Other) Resource Domain (Windows ) ADFS Resource Server WS-Federation-Compatible Account Server (ADFS or Other) Token Source Token Source 4) Receive token for resource server 2) Request SAML token for application and get redirected to account server Token SAML Token for Resource Server 3) Authenticate and request token for resource server ADFS Agent Application Web Browser Windows Server 2003 R2 1) Access application and get redirected to resource server
ADFSAcquiring and using a token across scopes (2) Account Domain (Windows or Other ) Resource Domain (Windows ) ADFS Resource Server WS-Federation-Compatible Account Server (ADFS or Other) Token Source Token Source 8) Use claims in token 6) Receive token for application SAML Token for Resource Server SAML Token for Application 5) Request token for application ADFS Agent Application SAML Token for Application Web Browser 7) Send token to application Windows Server 2003 R2
Identity on the Internet • Most Web applications use Username/Passwordtoday • Pros: • Easy to implement • Easy for users to access apps from different machines • Cons: • Easy to steal and reuse: phishing
Identity on the InternetA claims-based alternative • Windows CardSpaceallowsa claims-based view of identity • It offers two choices: • Using identities issued by CardSpace’sself-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
Username/PasswordAcquiring and using a token Identity Provider Windows Domain 3) Extract claims (username and password) from token 1) Provide username and password Application Client Windows 4) Look up user, authenticate, and (optionally) find other information Internet Token 2) Send username/ password token
Windows CardSpaceUsing a token from a self-issued provider Identity Provider Windows CardSpace Self-Issued Provider Windows Domain Token Source 3) Extract claims (PPID, etc.) from token 1) Acquire CardSpace self-issued token SAML Token Application Store Client Internet Windows 4) Look up user and find other information SAML Token 2) Send CardSpace self-issued token
Windows CardSpaceUsing a token from a managed provider Managed Identity Provider 1 Managed Identity Provider N Windows Domain Security Token Service (STS) Security Token Service (STS) . . . 3) Extract claims from token 1) Acquire token Token Store Application Client Internet 4) Look up user and find other information Windows Token 2) Send token
Windows CardSpaceLooking ahead • 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
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 2007An illustration Identity Store Identity Store Identity Store Identity Store Microsoft Exchange Server IBM Mainframe Application SAP SQL Server Identity Lifecycle Manager 2007 If … Then … If … Then … If … Then … Rules Actions Identity Store Identity Store Identity Store AD Domain Services AD Lightweight Directory Services Novell eDirectory
ConclusionWhat 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
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.