CIS14: Identity at Scale: Next Gen Federation Architectures
3 likes875 views
The document discusses challenges and strategies for scaling federated identity management (FIdM) in the context of growing digital demands. It presents a range of solutions including proxy services, metadata management, and self-service registration for efficient trust establishment and connection management. The recommendations call for separating trust management from protocol runtime to enhance interoperability and scalability beyond existing limitations.
![• No overarching trust model
– compare to SSL & Server Cert PKI
• No trust model, p2p
– No way forward to the IoT
• 3rd party provided trust is key
– compare to SSL CA
• Apply to / across:
– Web SSO and API Access
– mutual authentication
• Technical Trust vs. Behavioral Trust
Trust Model
Beyond Standards and Protocols
[1] http://shop.soundingboardink.com/shop/2011/01/18/an-operational-definition-of-trust/!](https://image.slidesharecdn.com/yskwd8amrjmdvjvadjyv-signature-e77353a5531666e85fadeb0e4ebdcbd4e7522e2f525b50388570d11bd88051f3-poli-140804141534-phpapp02/85/CIS14-Identity-at-Scale-Next-Gen-Federation-Architectures-4-320.jpg)
CIS14: Identity at Scale: Next Gen Federation Architectures
- 1. NEXT GEN FEDERATION ARCHITECTURES Identity at Scale July 21st – Cloud Identity Summit 2014 Hans Zandbelt - CTO Office – Ping Identity Copyright © 2014 Ping Identity Corp.All rights reserved. 1
- 2. Overview 1 • Challenges in Federated IDM 2 • Strategies for Scaling FIDM 3 • Now What?
- 3. • Manual Creation/Mgmt – 1-1 – Increasing numbers • Authoritative/authenticated source • Updates – Key rollover(!) Challenges Federated Identity Today IDPSP IDPSP IDPSP
- 4. • No overarching trust model – compare to SSL & Server Cert PKI • No trust model, p2p – No way forward to the IoT • 3rd party provided trust is key – compare to SSL CA • Apply to / across: – Web SSO and API Access – mutual authentication • Technical Trust vs. Behavioral Trust Trust Model Beyond Standards and Protocols [1] http://shop.soundingboardink.com/shop/2011/01/18/an-operational-definition-of-trust/!
- 5. Architecture Evolution 1 App Fed App Fed App Fed 2 Federation Application/Access Server App App App 3 App App App Federation Server App. Server App. Server 4 Connection Management App Fed App Fed App App App. Server Federation
- 6. Architectural Separation of Concerns • Data Layer – Protocol Runtime – Message Processing • Control Layer – Technical Trust (protocol independent) – Connection Management Copyright © 2014 Ping Identity Corp.All rights reserved. 6
- 7. Trusted Shared Service • Single/central/shared point of connection management (trust) • Trusted 3rd party • From: user trust scale through 2nd party to SP/IDP trust through 3rd-party • Compares to TLS CA or DNS(sec) root hierarchy • Challenge: problem reduced in size, shifted up one level IDPSP IDPSP IDPSP
- 8. • Outsource metadata management to a central inband service • Trust proxy only, relay to peers, inhouse/outhouse • MxN -> M+N connections • Technical trust may be combined with organizational trust • Accommodate for different SAML implementations & protocol translations Solution 1: Proxy IDPSP IDPSP IDPSP Proxy SPIDP
- 9. Metadata • Outsource metadata management to a central out- of-band service • aka. multi-party federation • Higher Education & Research: InCommon, UK Access Federation, 50+ • Async technical trust (M+N) • Sync direct peer-to-peer communication (MxN) • Metadata upload (!) Solution 2: Metadata Service IDPSP IDPSP IDPSP SAML
- 10. • 1-sided responsibility instead of mutual – Google SAML, Salesforce SAML, OIDC Dynamic Client Registration • MxN connections+trust, but burden shifted to 1 party – SAML: IDP, OIDC: RP – Shift rather than reduce Solution 3*: Self Service / Registration Copyright © 2014 Ping Identity Corp.All rights reserved. 10 IDPSP IDPSP IDPSP
- 11. Network Applications IDENTITY ¤ • Scalable Identification • Scalable Security – Authentication, Privacy, Confidentiality, Integrity • Scalable Trust • Scalable Attribute Exchange – schemas The Identity Layer
- 12. OpenID Connect • Discovery & Dynamic registration – auto-creation – auto-update (!) • Easier to develop, deploy, manage • Technical trust OOTB – except for “disconnected” domains -> metadata service • DEMO? Copyright © 2014 Ping Identity Corp.All rights reserved. 12
- 13. • Separate protocols for SSO and API security • Heavyweight - in payload and processing • Complex – develop and manage • Manual trust bootstrapping and certificate management* (it’s alive) • SSO and API security in one • Lightweight – mobile • Simple – developer friendly • Auto client registration and key management SAML and OpenID Connect SAML OpenID Connect
- 14. Recommendations • Adopt solutions for Scaling Federated IDM beyond 2015 or 50 connections – Short-term: auto-updates, long-term: auto-creation – Multi/cross protocol -> trust framework & mechanisms • Separate Trust/Connection Management from Protocol Runtime – control plane and data plane + trust framework • Global solution? – A combination of Proxy & Metadata Service & Self-Service Copyright © 2014 Ping Identity Corp.All rights reserved. 14
- 15. Thank You http://www.pingidentity.com Hans Zandbelt hzandbelt@pingidentity.com Twitter: @hanszandbelt QUESTIONS?