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:saml-support@idp.example.org</
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
D
N
S
IDP
D
N
S
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
OPRP
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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to CIS13: Identity at Scale

Similar to CIS13: Identity at Scale (20)

More from CloudIDSummit

More from CloudIDSummit (20)

Recently uploaded

Recently uploaded (20)

CIS13: Identity at Scale