This document provides an overview of digital identity and single sign-on using Windows Identity Framework. It discusses problems with separate user stores per application and outlines how claims, security token services, Active Directory Federation Services, and Windows Identity Foundation can provide a common identity model to solve these problems. It then describes passive and partner federation scenarios and concludes with a demo.

1. Windows Identity FrameworkAn overview of digital identity and single sign on.

2. AgendaWhat problems are we trying to solve

3. Claims

4. Security Token Service (STS)

5. Active Directory Federation Services (ADFS 2.0)

6. Claims Aware Application

7. Windows Identity Foundation (WIF)

8. Passive Federation (Intranet Scenario)

9. Partner Federation

10. DemoWhat problems are we trying to solve?One user store per application

11. The amount of identities users must relate to (roles, groups)

12. Increasing cost around administration and maintenance of user stores

13. Lack of control over user identities, both by user himself and the organizations

14. When someone quits, how many identities in how many systems must be deactivated ?

15. Single Sign-OnClaimsNot limited in the same way as e.g. Windows Tokens (Kerberos) - Username - Groups…or ASP.NET membership provider: - User - Roles - Profiles

16. Claims (contd..)Claims can carry more information about the user, roles, email, age…anything

17. Applications using Claims have one common model.

18. Anonymize users (IsOver18).

19. Can be accessed over internet as well as intranet.

20. Can work with browsers and web services.

21. The Name Claim and Role Claim is something that .NET understands today.: - HttpContext.Current.UserIPrincipal (IsInRole) - HttpContext.Current.User.IdentityIIdentity (Name, IsAuthenticated)Security Token Service (STS)A centralized service for authentication outside the application (separation of concern)

22. Talks to other STSs with partner organization

23. Issues and transforms ClaimsActive Directory Federation Services (ADFS 2.0)Microsoft STS

24. Integrated with Active Directory

25. Supports both active as well as passive clients

26. Can integrate with other WS-trust, and other STS’s

27. Supports SAML 1.1 and 2.0 Tokens.

28. Supports WS-Fed (1 and 2) and SAML 2.0 protocol (not 1.1)

29. Two flavors : Service and ProxyClaims Aware ApplicationThe application makes authorization decisions based on the claims contained in the security token

30. No longer required to make authentication decisions

31. Same authorization logic for Application

32. Deployed on the Intranet or as a Cloud service

33. Receiving claims from its own organization’s users or users from trusted partners Windows Identity Foundation (WIF)Provides a common programming model for claims.

34. Validates incoming security token parses claims that are inside.

35. Reduces complexity and necessary code to implement security in .NET apps. (no need to be a security expert)

36. Provides plumbing tools integrated into Visual studio to configure .NET apps to use Claims and STS’s

37. Works with WCF and ASP.NET applications.Passive Client (Intranet scenario)UserClaims-aware appADFS STSActive DirectoryUserApp trusts STSBrowse appNot authenticatedRedirected to STS AuthenticateReturn Security TokenQuery for user attributesSend TokenSTSTReturn pageand cookie

38. YourADFS STSYourClaims-aware appPartner ActiveDirectoryPartnerADFS STS & IPPartner userBrowse appNot authenticatedRedirect to your STSHome realm discoveryRedirected to partner STS requesting ST for partner userAuthenticateReturn ST for consumption by your STS Redirected to your STS STSTSTSTProcess tokenReturn new ST Send TokenReturn pageand cookie

39. DEMO

40. Q&AManu Sharma Senior Software DeveloperManu.Sharma@blackline.comMore Infohttp://msdn.microsoft.com/en-us/security/aa570351

41. Thank You!