CIS13: Identity at Scale
1 like•957 views
This document discusses solutions for managing identity at scale. It begins by describing trends like cloud computing, mobile devices, and the internet of things that are increasing the need for identity management. It then examines challenges like maintaining metadata across many connections. Two proposed solutions are a proxy that manages connections indirectly, and a metadata service that allows centralized management of metadata. The document recommends a metadata service approach that supports multiple protocols and can combine with proxy solutions for different deployment scenarios. This would help scale identity management to a global level.
CIS13: Identity at Scale
- 1. Copyright ©2013 Ping Identity Corporation. All rights reserved.1 Identity at Scale Hans Zandbelt CTO Office – Ping Identity CIS 2013
- 2. Copyright ©2013 Ping Identity Corporation. All rights reserved.2 • Trends and Standards • Identity at Scale • Recommendations Contents
- 3. Copyright ©2013 Ping Identity Corporation. All rights reserved.3 Trends • Cloud (SaaS), Mobile, Social – Authentication: SAML -> +OpenID Connect • Web -> API – Core business: information and data, not presentation • Internet of Things • Mutual authentication? – controlling other cars, toasters, lightbulbs
- 4. Copyright ©2013 Ping Identity Corporation. All rights reserved.4 • Standards – Interoperability: need to deal with another vendor’s API/ product? Not an app for every thing in the IoT! – cross-domain – competition, replaceable implementations, leading to good but cheap products? • APIs – Light-weight, SOAP -> REST/OAuth 2.0 • Web SSO – Enterprise/Customer Identity, Consumer Identity – SAML -> OpenID Connect : scale? • OpenID Connect – Simplicity for clients/RPs -> complexity shifted to the OP Standards (the nice thing is…)
- 5. Copyright ©2013 Ping Identity Corporation. All rights reserved.5 IDENTITY AT SCALE
- 6. Copyright ©2013 Ping Identity Corporation. All rights reserved.6 1-1 Federated Identity Today • Increase of Cloud/SaaS adoption – # federated SSO applications (SAML) – # partner connections – # connection management overhead (*) • But(!) also for “incidental” connections – How to obtain updates • Authoritative source -> trust • Infrastructure: authenticated source (e-mail…) – How to configure them • Automated • Managed, outsourced IDP IDP IDP SP SP SP
- 7. Copyright ©2013 Ping Identity Corporation. All rights reserved.7 • Metadata related (not so standard for other-than-SAML protocols) – key material – SSO service URLs – point of contact • Attributes – could be metadata, often isn’t – may be bilateral (!) – required/optional, consent • Policies – contractual agreements – privacy • End-user/application/SSO related – how users can sign in (relation to service URLs) – change in look and feel – change in functionality (*) Connection Management <md>
- 8. Copyright ©2013 Ping Identity Corporation. All rights reserved.8 Metadata - SAML 2.0 • Technical Trust • X.509 Certificate – Anchored vs. unanchored – Key vs. other cert info • URLs/Bindings • Contact info – Company name, admin/tech contact <md:EntityDescriptor! xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"! xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"! xmlns:ds="http://www.w3.org/2000/09/xmldsig#"! entityID="https://idp.example.org/SAML2">! ! <!-- insert ds:Signature element -->! ! <md:IDPSSODescriptor! protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">! ! <md:KeyDescriptor use="signing">! <ds:KeyInfo>…</ds:KeyInfo>! </md:KeyDescriptor>! ! <md:SingleSignOnService! Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"! Location="https://idp.example.org/SAML2/SSO/POST"/>! <md:SingleSignOnService! Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"! Location="https://idp.example.org/SAML2/Artifact"/>! ! </md:IDPSSODescriptor>! ! <md:Organization>! <md:OrganizationName xml:lang="en">! SAML Identity Provider ! </md:OrganizationName>! <md:OrganizationURL xml:lang="en">! http://www.idp.example.org/! </md:OrganizationURL>! </md:Organization>! ! <md:ContactPerson contactType="technical">! <md:SurName>SAML IdP Support</md:SurName>! <md:EmailAddress>mailto:[email protected]</ md:EmailAddress>! </md:ContactPerson>! ! </md:EntityDescriptor>!
- 9. Copyright ©2013 Ping Identity Corporation. All rights reserved.9 Connection Management Metadata/Technical Issues • Conn Mgmt often a one-shot process (cq. a snapshot) • Certificate expiry and update • Contact info update • URL and binding updates • Changes in IDP discovery process • Metadata documents can contribute to the solution, but how to scale exchange? Key Rollover Contact Info Bindings & URLs
- 10. Copyright ©2013 Ping Identity Corporation. All rights reserved.10 Contrary to popular belief: The connection management problem is NOT specific to SAML; any federated authentication system deployed on true internet scale will have to address this issue. So: any solution should be protocol agnostic. BE AWARE
- 11. Copyright ©2013 Ping Identity Corporation. All rights reserved.11 TOWARDS A SOLUTION What can we do?
- 12. Copyright ©2013 Ping Identity Corporation. All rights reserved.12 Solution Approach (n=2): Shared Conn. Mgmt. • 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 and a Certificate Authority or DNS • Challenge – How to create a trusted channel Shared Service IDP IDP IDP SP SP SP
- 13. Copyright ©2013 Ping Identity Corporation. All rights reserved.13 A shared service… where does it apply? • intra-enterprise – large distributed organizations, both infrastructure and responsibilities/trust (acquisitions and mergers) – connect multiple applications to a variety of externals & internals; “user access firewall” • inter-enterprise – verticals: healthcare, automotive, banking/ financial, education but also "cross e-Gov” – homogeneous(!) group with shared interest/organization IDP SP IDP SP IDP SP IDP SP
- 14. Copyright ©2013 Ping Identity Corporation. All rights reserved.14 A Next Step In Architecture Evolution… Application Server App 1 Fed Fed Fed App 2 App 3 App Server or Access System App 1 Federation App 2 App 3 App Server App 1 Federation Server App 2 App 3 App Server App Srv App 1 Fed Server App 2 App Srv Connection Management App Server App 3 Fed Fed App 4 1 2 3 4
- 15. Copyright ©2013 Ping Identity Corporation. All rights reserved.15 Solution 1: Proxy • Indirect peer-to-peer communication • Trust proxy only, relay to peers, inband • Shift the metadata problem to a central facility: no distr. mgmt • Technical trust may be combined with organizational trust • Connection Mgmt – MxN -> M+N • Accommodate for diff SAML implementations • Protocol translations are possible Operator IDP IDP IDP SP SP SP SAML Proxy SP-IDP SAML
- 16. Copyright ©2013 Ping Identity Corporation. All rights reserved.16 Benefits • Scalability of trust – Technical: single connection to proxy, central management of partner connections – Organizational: trust in proxy operator • Updates – outsourced to the proxy; proxy to solve… • Discovery & Autoconf – Outsourced to the proxy; proxy to solve… Centralized Trust Mgmt Updates Discovery & Autoconf
- 17. Copyright ©2013 Ping Identity Corporation. All rights reserved.17 Solution 2: Metadata Service • aka. multi-party federation • Higher Education & Research – InCommon, UK Access Federation – 40+ across the world • Business Verticals – Healthcare – Finance – e-Gov • Async technical trust • Sync direct peer-to- peer communication • Metadata upload (!) Federation Operator IDP IDP IDP SP SP SP SAML Metadata
- 18. Copyright ©2013 Ping Identity Corporation. All rights reserved.18 Distribution variants (SAML 2.0 metadata) • Flat file based (classic) – > 10 Mb files for large federations (EntitiesDescriptor) • Query-based (MDX) • Well known location for metadata – EntityID-is-URL-to- Metadata – SAML auto-connect (Ping Identity) • DNS based (registry) • Trust 1. signed metadata 2. trusted registry 3. SSL CA IDP SP IDP SP IDP SP IDP SP IDP IDP D N S IDP D N S 1 2 3
- 19. Copyright ©2013 Ping Identity Corporation. All rights reserved.19 Metadata Expiry (!) • Attributes on Entity and Entities level: validUntil and cacheDuration • On EntitiesDescriptor and EntityDescriptor level • use only validUntil to enforce expiration • use cacheDuration to override (downward) the refresh interval • keep using (valid) metadata if the refresh fails d! t1! t1+d! t1+2d! v=t2! t2+d! t2+2d! d = cacheDuration (interval)! v = validUntil (timestamp)! d!
- 20. Copyright ©2013 Ping Identity Corporation. All rights reserved.20 Benefits • Scalability of trust – Technical: removes need to exchange metadata on peer-to- peer basis – Organizational: federation operator does IDP and SP vetting through contractual agreements • Key rollover – Include multiple signing keys for a <validUntil> period • Discovery and auto- configuration – Building block… Scalability of Trust Key Rollover Discovery & Autoconf
- 21. Copyright ©2013 Ping Identity Corporation. All rights reserved.21 Metadata Service layering: interfederation Interfederation Operator IDP IDP SP SP IDP IDP SP SP Metadata Metadata Aggregated Metadata
- 22. Copyright ©2013 Ping Identity Corporation. All rights reserved.22 • MDUI – SAML version 2.0 Metadata Extensions for Login and Discovery User interface, version 1.0 • Entity attributes – SAML V2.0 Metadata Extension for Entity Attributes Version 1.0 – Generic extension point • Signed Entity Attributes – Single source of metadata, support multiple trust levels or hierarchies • Other protocols – SAML 1.0, SAML 1.1 – WS-Federation (ADFS 2.0) – OpenID 2.0 – OpenID Connect (?) -> independent registry or attr SAML 2.0 Metadata extensions
- 23. Copyright ©2013 Ping Identity Corporation. All rights reserved.23 Taxonomy + Examples External Internal Model Proxy Metadata IDMaaS (PingOne) Federation (InCommon) Proxy (PingFed`) “Metadata Server” Deployment
- 24. Copyright ©2013 Ping Identity Corporation. All rights reserved.24 • Proxy – PingOne – wayf.dk • Metadata Service – InCommon – UK Access Federation Any SAML product implementation today may or not support one or both models, in the core or through customizations. Solution Examples for SAML 2.0
- 25. Copyright ©2013 Ping Identity Corporation. All rights reserved.25 OpenID Connect Metadata (OP and RP) • Metadata and key material separated • Use HTTP cache info for the JWK set (optional) • Multiple keys with “kids” – JIT: client fetches kid if unknown • Client updates keys with OP through DynReg OPRP JWK set metadata JWK set metadata Metadata Service Dynamic Client Registration
- 26. Copyright ©2013 Ping Identity Corporation. All rights reserved.26 RECOMMENDATIONS
- 27. Copyright ©2013 Ping Identity Corporation. All rights reserved.27 • The problem is not protocol specific (!) – Any solution should be multi-protocol enabled or rather protocol agnostic • A shared service, two possible approaches – Metadata Service (“automate”) or Proxy (“outsource”) • True Internet scale? Expect combinations (!) – Local/enterprise/community: proxy based – Protocol Translation: proxy – Global: (interconnected) metadata service based Recommendations
- 28. Copyright ©2013 Ping Identity Corporation. All rights reserved.28 • Registration and publishing service for “endpoint” metadata – Multi-protocol: both SAML 2.0 and OpenID Connect (OPs) • Technical Trust – authenticated, trusted source • Discovery – multiple entities on a single OIDC domain – Entities that cannot or will not host their own metadata – Replace well-known URL starting point • Validation • Certification Metadata Service
- 29. Copyright ©2013 Ping Identity Corporation. All rights reserved.29 Future? Not so much! • Identity is/as KEY – not just users, but also devices and applications • Unified access policy implementation across web and APIs/Mobile – Based on identity • Enterprise: – Single System -> Identity Bridge • Identity Bridge – Bridge external SAML and OpenID Connect to internal OpenID Connect (both ends standardized)
- 30. Copyright ©2013 Ping Identity Corporation. All rights reserved.30 Thank You Q&A @hanszandbelt Ping Identity