0
NEXT GEN FEDERATION
ARCHITECTURES
Identity at Scale
July 21st – Cloud Identity Summit 2014
Hans Zandbelt - CTO Office – Pi...
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(!)
C...
•  No overarching trust model
–  compare to SSL & Server Cert PKI
•  No trust model, p2p
–  No way forward to the IoT
•  3...
Architecture Evolution
1
App
Fed
App
Fed
App
Fed
2
Federation
Application/Access Server
App App App
3
App App App
Federati...
Architectural Separation of Concerns
• Data Layer
– Protocol Runtime
– Message Processing
• Control Layer
– Technical Trus...
Trusted Shared Service
•  Single/central/shared point of
connection management (trust)
•  Trusted 3rd party
•  From: user ...
•  Outsource metadata
management to a central
inband service
•  Trust proxy only, relay to peers,
inhouse/outhouse
•  MxN ...
Metadata
•  Outsource metadata
management to a central out-
of-band service
•  aka. multi-party federation
•  Higher Educa...
•  1-sided responsibility
instead of mutual
–  Google SAML, Salesforce
SAML, OIDC Dynamic
Client Registration
•  MxN conne...
Network
Applications
IDENTITY
¤
•  Scalable Identification
•  Scalable Security
–  Authentication, Privacy,
Confidentiali...
OpenID Connect
•  Discovery & Dynamic registration
–  auto-creation
–  auto-update (!)
•  Easier to develop, deploy, manag...
•  Separate protocols for SSO and API
security
•  Heavyweight - in payload and
processing
•  Complex – develop and manage
...
Recommendations
•  Adopt solutions for Scaling Federated IDM beyond 2015 or 50
connections
–  Short-term: auto-updates, lo...
Thank You
http://www.pingidentity.com
Hans Zandbelt
hzandbelt@pingidentity.com
Twitter: @hanszandbelt
QUESTIONS?
Upcoming SlideShare
Loading in...5
×

CIS14: Identity at Scale: Next Gen Federation Architectures

332

Published on

Hans Zandbelt, Ping Identity

Overview of the challenges we face when scaling up federation infrastructures, exploring possible ways to move forward and discussing protocols and concrete deployment architectures that allow for realizing Identity at Scale.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
332
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "CIS14: Identity at Scale: Next Gen Federation Architectures"

  1. 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. 2. Overview 1 • Challenges in Federated IDM 2 • Strategies for Scaling FIDM 3 • Now What?
  3. 3. •  Manual Creation/Mgmt –  1-1 –  Increasing numbers •  Authoritative/authenticated source •  Updates –  Key rollover(!) Challenges Federated Identity Today IDPSP IDPSP IDPSP
  4. 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. 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. 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. 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. 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. 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. 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. 11. Network Applications IDENTITY ¤ •  Scalable Identification •  Scalable Security –  Authentication, Privacy, Confidentiality, Integrity •  Scalable Trust •  Scalable Attribute Exchange –  schemas The Identity Layer
  12. 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. 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. 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. 15. Thank You http://www.pingidentity.com Hans Zandbelt hzandbelt@pingidentity.com Twitter: @hanszandbelt QUESTIONS?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×