cis13: identity at scale

Copyright ©2013 Ping Identity Corporation. All rights reserved. 1

Identity at Scale

Hans Zandbelt CTO Office – Ping Identity

CIS 2013


•  Trends and Standards •  Identity at Scale •  Recommendations

Contents


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


•  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…)


IDENTITY AT SCALE


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


•  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>

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">!! !! <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>!


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


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


TOWARDS A SOLUTION What can we do?


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


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


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


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


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


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


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

DNS

IDP

DNS

1 2 3


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!


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


Metadata Service layering: interfederation

Interfederation Operator

IDP

IDP

SP

SP

IDP

IDP

SP

SP

Metadata Metadata

Aggregated Metadata


•  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


Taxonomy + Examples

External

Internal

Model Proxy Metadata

IDMaaS (PingOne)

Federation (InCommon)

Proxy (PingFed`)

“Metadata Server”

Deployment


•  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


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

OP RP

JWK set

metadata

JWK set

metadata

Metadata Service

Dynamic Client

Registration


RECOMMENDATIONS


•  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


•  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


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)


Thank You

Q&A @hanszandbelt

Ping Identity

cis13: identity at scale

Technology

ping identity corporation

app server app srv app

federated identity

standards identity

saml identity provider

fed server app

federation app

federation server app