Post on 08-Sep-2014
description
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
Overview
1 • Challenges in Federated IDM
2 • Strategies for Scaling FIDM
3 • Now What?
• Manual Creation/Mgmt
– 1-1
– Increasing numbers
• Authoritative/authenticated source
• Updates
– Key rollover(!)
Challenges
Federated Identity Today
IDP SP
IDP SP
IDP SP
• 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/!
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
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
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
IDP SP
IDP SP
IDP SP
• 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
IDP SP
IDP SP
IDP SP
Proxy
SP IDP
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
IDP SP
IDP SP
IDP SP SAML
• 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
IDP SP
IDP SP
IDP SP
Network
Applications
IDENTITY ¤
• Scalable Identification
• Scalable Security
– Authentication, Privacy, Confidentiality, Integrity
• Scalable Trust
• Scalable Attribute Exchange
– schemas
The Identity Layer
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
• 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
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
Thank You
http://www.pingidentity.com
Hans Zandbelt hzandbelt@pingidentity.com
Twitter: @hanszandbelt
QUESTIONS?