Single SignOn with Federation using Claims


Published on

This is a presentation that talks about SSO, Claims based authenticarion, SAML2 protocol.

Published in: Internet, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • World was smallAuthentication was easy (or was it?)Apps has/d their own directoriesThere weren't many outsiders
  • IIDentity=>IsAuthenticated, NameIprincipal=> IsInRole, IIDentityWCF model is different???
  • Single SignOn with Federation using Claims

    1. 1. Federation, SSO,Claims Volkan Uzun
    2. 2. About Me Software Dev Staff Engineer @ Dell @ RD Working on Identity Management Applications Blog: Twitter: @volkanuzun Email:
    3. 3. Authentication/Authorization
    4. 4. Why Identity Federation? • Decouple authentication mechanism from applications and services • Go claims-based • Reduce IT pain and risk related to provisioning and de-provisioning users • Extend trust to users across domain, corporate and Internet boundaries • Support Single Sign-On (SSO)
    5. 5. Decouple Authentication • Windows/Kerberos • Forms authentication • HTTP basic authentication • SSL Certificates • WS-Fed • WS-Trust • SAML • OAuth (authorization , people use it wrong!) • OpenID (authentication)
    6. 6. Claims Any information about a subject from a provider. Identity providers typically issue claims based on the user’s identity Authenticate
    7. 7. Claims Applications may transform identity claims into application-specific claims Transform
    8. 8. Token • Contains the claims • The signature • Information about the issuer • May be encrypted • In XML format • Has an expiration date • SAML 1.1/2.0, Simple Web Token, JSON Web Token
    9. 9. Token Types • SAML XML based, encryption and signature with asymmetric or symmetric, processing power • Simple Web Token (SWT) URL/Form encoded, symmetric signature only • JSON Web Token (JWT) The new cool guy, symmetric or asymmetric, JSON encoded
    10. 10. Claims-based Identity Pros Before Claims-based: • App authenticated the user or relies on 3rd party to authenticate such as AD • App gets simple information from user, such user name. After Claims-based: • Authentication is outsourced to STS • App gets any information it needs
    11. 11. STS • Security Token Service • Claims are issued by a provider (STS) • A security token service (STS) is the service component that builds, signs, and issues security tokens • Client applications trust STS • The basic flow is: Client requests token, issuer issues token, resource consumes the token
    12. 12. Passive Federation IdP DomainRP Domain 2SignIn Web Site (RP) Authorize Access 7 Quest STS (IdP) 5Authenticate / Issue Token Browser (requestor) Login Page POST Credentials 3 41 POST SignIn Response 6 User (subject)
    13. 13. Active Federation RP DomainIdP Domain Rich Client Identity Provider (IdP) Application (Relying Party, RP) 1 3 4 2 Authenticate / Issue 5 Authorize Credentials Security Token / Claims
    14. 14. Certificate • Token is signed with certificate • Same cert maybe used for encrypting the message • Same cert maybe used for cookie encryption • Cert Type
    15. 15. .NET help me please RBAC (Since 2002) IIdentity IPrincipal IIdentity: IsAuthenticated; AuthenticationType; Name IPrincipal: IIdentity; IsInRole(string roleName); Thread.CurrentPrincipal
    16. 16. DEMO Old style 
    17. 17. First Attempt: WIF Windows Identity Foundation • Hooks into ASP.NET pipeline • Not a new solution: Claims • Embedded into the .NET 4.5
    18. 18. ClaimsIdentity, ClaimsPrincipal ClaimsIdentity:IIdentity {IEnumerable<Claim>Claims} ClaimsPrincipal:IPrincipal {ReadOnlyCollection<ClaimsIdentity>Identities}
    19. 19. DEMO Visual Studio 2010 Demo with WIF Visual Studio 2012 Demo with .NET 4.5
    20. 20. SSO • Client applications are responsible for authorization (cookie) • STS is responsible for user authentication. (cookie) • STS can generate the session token from the cookie • STS can reissue the session token from the cookie
    21. 21. Log Out • More difficult than login • STS has to delete its own cookie • Each client application must be notified for a logout
    22. 22. Partner Federation • Your STS acts as a client application for another STS • When your STS doesn’t have the user identity • Client application still trusts only your STS • Your STS does claims transformation
    23. 23. Home Realm Redirection IdP DomainApplication Domain Browser 1 2 3 11 Sign-In Request 5 4 POST Credentials Set Cookie 7 IdP SAML 9 Web Site Authorize Access 10 Quest STS 8 IdP STS 6Authenticate / Issue Token Login Page Sign-In Request Gather Attributes/ Issue Assertion Keystone Assertion w/ Session Token
    24. 24. Warnings • Caching SessionSecurityToken • Cookie size may be an issue (even with chunking) • Infinite loops (cookie issue) • Load balancer issue (cookie issue) • Use SSL • QueryString length may be an issue