Download as PDF, PPTX
Uploaded byWSO2
Practical Federated Identity
This document discusses practical use cases of federated identity in real world scenarios. It begins by defining identity and explaining problems with digital identity, such as having separate identities in different applications. It then introduces federated identity as a way to make identities portable across domains. Key requirements for federated identity include identity management, authentication, trust between domains, attribute mapping, and attribute exchange. Common protocols for federated identity include OpenID, SAML, and WS-Trust. The document provides examples of federated identity patterns using WSO2 Identity Server and discusses use cases such as a SaaS application with trusted identity providers.
More Related Content
![[OPD 2019] Attacking JWT tokens](https://cdn.slidesharecdn.com/ss_thumbnails/attackingjwttokens-191021171156-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Practical Federated Identity
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=640&height=640&fit=bounds)
Practical Federated Identity
- 1. Practical Federated Identity UseCases From The Real World Johann Nallathamby, Senior Software Engineer Selvaratnam Uthaiyashankar, Director-Cloud Solutions
- 2. What is Iden,ty • “the fact of being who or what a person or thing is” • h3p://oxforddic8onaries.com/defini8on/ english/iden8ty • Who you are… • Why important? • Whatever you do associated with your iden8ty • Digital Iden8ty
- 3. Problems with Digital Iden,ty • Different Iden8ty in Different Applica8ons / Domains – Remembering Password – Loosing possible collabora8on
- 4. Federated Iden,ty • “The agreements, standards, and technologies that make iden8ty and en8tlements portable across autonomous domains.” -‐ Burton Group Service Providers Service Providers Service Providers Identity Provider Service Providers Authentication Service Consumption Trust
- 5. Key Requirements For Iden,ty Federa,on Iden,ty Management and Authen,ca,on • Authen8ca8on – Mul8-‐Factor Authen8ca8on • Iden8ty Management – A3ributes / Claims
- 6. Key Requirements For Iden,ty Federa,on Trust Between Domains • Trust – Pre-‐established • Common in Enterprise scenarios – Established only when accessing the service • Common in web scenarios • Iden8ty Provider Discovery
- 7. Key Requirements For Iden,ty Federa,on Iden,ty and AAribute Mapping • Mapping user iden8ty of one system to another – Username – Out of Band – Pseudonym • Transient • Persistent • Mapping a3ribute names in different systems • Mapping a3ribute values in different systems
- 8. Key Requirements For Iden,ty Federa,on AAribute Exchange • One system reques8ng addi8onal a3ributes from another system
- 9. Protocols and Standards • OpenID • SAML2 Web Browser SSO • WS-‐Trust & WS-‐Federa8on
- 10.
- 11. OpenID Iden,fiers • Google – h3ps://profiles.google.com/YourGoogleID • Blogger – h3p://blogname.blogspot.com/ • MySpace – h3p://www.myspace.com/username
- 12. OpenID Identity Provider ServiceProvider A Provide OpenID Single Sign-On Service 1 2 4 5 4 Allow Access to Service Relying Party Browser Redirect to IdP Discover Provider (XRI Resolution, Yadis, HTML Based Discovery) 6 7 3 Create shared secret
- 13.
- 14.
- 15. SAML2 Web Browser SSO Identity Provider Service Provider A Access Service Single Sign-On Service 1 23 5 4 Allow Access to Service Trust Assertion Consumer Service Browser Redirect to IdP Select Identity Provider 6 7
- 16. Demo – SAML2 Web Browser SSO
- 17. WS-‐Trust Identity Provider ServiceProvider A Authentication (Username/x509/etc.) Security Token Service 1 2 3 5 4 Verify Token (e.g.: Check signature) Security Token Trust
- 18. Some Federa,on PaAerns Using WSO2 Iden,ty Server
- 19.
- 20.
- 21.
- 22.
- 23. Resource STS PaAern Client STS Client Proxy Resource Proxy Resource STS
- 24. OAuth AS DMZ Proxy STS Federa,on for REST APIs
- 25. SaaS Applica,on with Trusted Iden,ty Providers • SaaS Applica8on • Application deployed by the super-tenant • Application used by all the tenants • Application authorization logic written against shared roles • Tenant users physically only exist in the Identity Provider and not in the Application server • The users’ attributes are with the Trusted Identity Provider • Trusted Iden8ty Providers (Trusted IdPs) • Each tenant will have its own Trusted Identity Provider • The SaaS application will delegate authentication by redirecting the user to the Trusted Identity Provider and then validate the signed token response with attributes. • Identity Provider roles are mapped to shared roles in the application server and authorization logic is performed based on them.
- 26. SaaS Applica,on with Trusted Iden,ty Providers
- 27.
- 28.
- 29. Photos Credit • h3p://images.motoring.co.uk/images/newsImages/ driving-‐licence-‐exchange-‐rules-‐ 8ghtened-‐52313-‐1.jpg • h3p://www.vectors4all.net/preview/people-‐ business-‐male-‐clip-‐art.jpg