1. Claims-Based Identity The path to federation and CardSpace

2. Outline Today’s identity challenges A more open identity model based on WS-* Security tokens Claims System.IdentityModel Security token services Claims transformation Identity federation

3. Typical Windows enterprise app Easy to make assumptions about user’s environment Users are all running Windows, Internet Explorer, etc. Users each have a Windows domain account Authorization options abound Access control lists Impersonation Role-based security Windows groups COM+ or AzMan roles Sql Server roles

4. Extending reach beyond the enterprise Many applications are outward facing B2B: servicing partnerships B2E: servicing remote employees B2C: servicing individual customers Can’t make the same assumptions in this case Not everyone runs Internet Explorer or even Windows Not all users are going to have the same security hardware Smart card readers? Biometric equipment? User account databases Provisioning, deprovisioning Password reset Maintaining authorization levels for users

5. Traditional solutions are not optimal Each company (often each application) keeps its own user db Yet another password for the user to track User identity becomes more and more fragmented into silos Solutions to synchronize these silos exist, but are costly Maintenance of each silo is costly Least common denominator authentication techniques used Not everyone has the same hardware or software Usually end up using passwords, which are weak today B2B scenario: Alice moves to another division Should she still have access to my application? When will the partner org notify me that she’s changed jobs? When will the partner org notify me if she quits?

6. In search of a better solution Goals Interoperability with other platforms Enable federation scenarios Reduce reliance on passwords Enable stronger authentication options Microsoft’s solution has several pieces System.IdentityModel Active Directory Federation Services (ADFS) The Identity Metasystem and CardSpace

7. Identity through the WS-* lens Two key WS-* specs lay the groundwork for an interoperable identity system WS-Security WS-Trust In a nutshell Identity details are packaged in security tokens Tokens contain a signed set of claims Each claim is a statement about a subject Tokens are issued by authorities via a security token service Applications can participate by accepting tokens issued by authorities that they trust WCF implements this model

8. Security tokens From WS-Security spec A security token represents a collection of claims A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or Kerberos ticket) WCF has plumbing to process tokens Decrypt token if necessary Check issuer’s name – do we trust this authority? Extract claims Verify issuer’s signature on the token Verify proof key claim Present claims to application

9. Traditional security tokens Kerberos ticket issued by Windows domain controller Session key Privilege Attribute Certificate (PAC) User SID Group SIDs Other user profile details PAC signed by domain controller X.509 Certificate Name Public key Key usage policies Certificate signed by issuer’s key You can look at the contents of these tokens as claims

10. Claims From WS-Security spec A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc.) Claims are very flexible “The subject’s name is Bob” “The subject’s email address is bob@fabrikam.com” “The subject has permission to access the purchasing app” “The subject may use resource X until 5pm on Thursday” “The subject is in the Sales department” “The subject is in the Foo role”

11. What’s in a claim? Each claim is identified by a URI URI’s in use will depend on context For example, CardSpace defines several claim URIs http://schemas.microsoft.com/ws/2005/05/identity/claims/givenna me http://schemas.microsoft.com/ws/2005/05/identity/claims/surname http://schemas.microsoft.com/ws/2005/05/identity/claims/emailadd ress Each claim can have a value

12. Claims in.NET 3.0 ClaimType is the claim URI as a string Right can be one of two things Identity PossessProperty Resource is the value of the claim namespace System.IdentityModel.Claims { public class Claim { public Claim(string claimType, object resource, string right); public string ClaimType { get; } public string Right { get; } public object Resource { get; } //... }

13. ClaimSet associates claims with issuers namespace System.IdentityModel.Claims { public abstract class ClaimSet : IEnumerable, IEnumerable { public abstract ClaimSet Issuer { get; } public virtual bool ContainsClaim(Claim claim); public abstract IEnumerable FindClaims(string claimType, string right); public abstract int Count { get; } public abstract Claim this[int index] { get; } public abstract IEnumerator GetEnumerator(); //... } Concrete derived classes  DefaultClaimSet  WindowsClaimSet  X509CertificateClaimSet

14. Claims in WCF WCF exposes claims to services via the AuthorizationContext Collection of ClaimSets Each ClaimSet represents the claims by a particular issuer

15. Example: looking at an X.509 certificate foreach (ClaimSet cs in ServiceSecurityContext.Current.AuthorizationContext.ClaimSets) { Console.WriteLine("*** begin claim set ***"); foreach (Claim c in cs.Issuer.FindClaims( ClaimTypes.X500DistinguishedName, Rights.PossessProperty)) { X500DistinguishedName dn = (X500DistinguishedName)c.Resource; Console.WriteLine("Issuer: {0}", dn.Name); } foreach (Claim c in cs.FindClaims( ClaimTypes.X500DistinguishedName, Rights.PossessProperty)) { X500DistinguishedName dn = (X500DistinguishedName)c.Resource; Console.WriteLine("Subject: {0}", dn.Name); } Console.WriteLine("*** end claim set ***"); }

16. Where do security tokens come from? Kerberos tickets Ticket issued by domain controller Typically expires at the end of the workday Local copy cached in memory in client’s logon session Packaged into an XML wrapper by client WCF plumbing X.509 Certificates Certificate issued by certificate authority Typically expires a year from issue date Local copy cached on client in certificate store Packaged into an XML wrapper by client WCF plumbing

17. Security Token Service (STS) WS-Trust defines an interoperable token issuance mechanism Called a security token service (STS) Can issue any type of token Kerberos tokens X.509 tokens SAML tokens etc. SAML tokens often used for interoperability Security Assertion Markup Language XML-based format suitable for representing signed claim sets

18. How an STS works User agent requests a security token from the STS Type of token desired (typically SAML) Scope of the token (which service does it apply to) Types of claims desired STS returns token to user agent Authenticates request Could use transport security Could use message security (implies a security token in the request) Creates a claim set, which typically includes a proof key Signs token Encrypts token so only service can read it Encrypts proof key so only client can read it

19. Example Client App Expense Report Service Expense Report Service ? 0. Client wishes to use a service that requires a SAML token

20. Example Client App AD 1.Client authenticates with Windows integrated authn to STS (Tx security) Expense Report Service Expense Report Service STS

21. Example Client App STS 1.Client authenticates with Windows integrated authn to STS (Tx security) 2.Client requests a token for the Expense Report app Expense Report Service Expense Report Service

22. Example Client App STS Expense Report Service Expense Report Service Authz Store 1.Client authenticates with Windows integrated authn to STS (Tx security) 2.Client requests a token for the Expense Report app 3.STS looks up client’s security profile and issues token

23. Example Client App Expense Report Service Expense Report Service 1.Client authenticates with Windows integrated authn to STS (Tx security) 2.Client requests a token for the Expense Report app 3.STS looks up client’s security profile and issues token 4.Client sends token to Expense Report service 5.Service validates token, uses claims to make security decisions

24. Interlude: service metadata and policy How does a client know what a service needs? What type of token does the service understand? What token issuer (STS) does the service trust? What types of claims does the service require? A service can inform clients of its security policy WS-Policy is designed to answer these sorts of questions in a platform-neutral way WCF generates this metadata for a service automatically

25. Claims transformation STS is all about claims transformation Consider the previous example Client started out with Windows credentials Service required a SAML token STS used client’s Windows account to authenticate her STS used that information to issue a SAML token These sorts of transformations help make federation possible Windows creds SAML token Client App STS

26. Claims transformation in the real world STS token

27. B2B collaboration In B2B scenarios, business partners establish a covenant that allows them to work together There exists some degree of trust A manufacturing company… Exposes an order processing app to its purchasing partners Talks to partners to learn which partner employees need access Issues user names and passwords to those users Determines privilege levels based on communication with partners Remember the costs associated with maintaining a user db? Remember the latency issues? How quickly does the manufacturing company discover that an employee of a partner has quit or changed jobs?

28. Identity federation Costs and latency can be reduced through automation Instead of issuing credentials to employees, we rely on the partner to authenticate them This gives us up-to-date information about the employee Is she still in a role that should allow her to use the app? Does she still work at the partner company? This solution is known as identity federation Microsoft’s approach relies on a few key elements: WS-* specifications SAML tokens Security token services Claims transformation

29. Identity federation example Client App Account STS Account STS Purchasing Service Purchasing Service Resource STS Resource STS Partner Company Manufacturing Company

30. Identity federation example Client App Account STS Account STS Purchasing Service Purchasing Service Resource STS Resource STS Partner Company Manufacturing Company Platform-specific strong creds SAML token A

31. Identity federation example Client App Account STS Account STS Purchasing Service Purchasing Service Resource STS Resource STS Partner Company Manufacturing Company SAML token A SAML token B

32. Identity federation example Client App Account STS Account STS Purchasing Service Purchasing Service Resource STS Resource STS Partner Company Manufacturing Company SAML token B

33. Identity federation example Account STS Account STS Partner Company Account-side STS authenticates clients using strong, platform-specific techniques Issues signed SAML token that partners on any platform can understand Can decide on a per-partner basis what claims to expose based on need-to-know Client App Purchasing Service Purchasing Service Resource STS Resource STS Manufacturing Company Manufacturing Company

34. Identity federation example Resource STS Resource STS Client App Account STS Account STS Purchasing Service Purchasing Service Partner Company Manufacturing Company Resource-side STS ensures all incoming SAML tokens are from trusted partners Transforms claims by reading incoming claims and writing a claim set that makes sense for the target application Can decide on a per-application basis what claims to expose based on need-to-know

35. Identity federation example Purchasing Service Purchasing Service Client App Account STS Account STS Resource STS Resource STS Partner Company Manufacturing Company Purchasing service verifies SAML token was issued by the resource STS. Doesn’t need to track a list of partners Receives claims that it understands May not need to know the identity of the user, only that the user is allowed to access the application with a certain level of privilege

36. Summary Today’s identity challenges A more open identity model based on WS-* Security tokens Claims System.IdentityModel Security token services Claims transformation Identity federation

37. Resources Technical Communities, Webcasts, Blogs, Chats & User Groups http://www.microsoft.com/communities/default.mspx http://www.microsoft.com/communities/default.mspx Microsoft Learning and Certification http://www.microsoft.com/learning/default.mspx http://www.microsoft.com/learning/default.mspx Microsoft Developer Network (MSDN) & TechNet http://microsoft.com/msdn http://microsoft.com/technet http://microsoft.com/msdn http://microsoft.com/technet Trial Software and Virtual Labs http://www.microsoft.com/technet/downloads/trials/defa ult.mspx http://www.microsoft.com/technet/downloads/trials/defa ult.mspx New, as a pilot for 2007, the Breakout sessions will be available post event, in the TechEd Video Library, via the My Event page of the website Required slide: Please customize this slide with the resources relevant to your session MSDN Library Knowledge Base Forums MSDN Magazine User Groups Newsgroup s E-learning Product Evaluations Videos Webcasts V-labs Blogs MVPs Certification Chats learn support connect subscribe Visit MSDN in the ATE Pavilion and get a FREE 180-day trial of MS Visual Studio Team System!

38. Complete your evaluation on the My Event pages of the website at the CommNet or the Feedback Terminals to win!

39. © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.