CIS 2015 Extreme SAML - Hans Zandbelt

Extreme SAML Hans Zandbelt

Overview

1.  Specification(s) 2.  Deployment 3.  Advanced Topics & Pitfalls 4.  Conclusions & Recommendations

Copyright © 2015 Cloud Identity Summit. All rights reserved. 2

Specification(s)


The Specifications

•  SAML 1.0: Nov 2002, 5 docs, 140 pages •  SAML 1.1: Sep 2003, 5 docs, 144 pages •  SAML 2.0: Mar 2005, 8 docs, 379 pages •  Old…, Large…, Difficult…, Ambiguous…, Extreme!

•  E.g. Optional elements in core may be mandatory in binding OR profile

•  Who implements what and how?


Foundations (of problems)


Heavyweight •  SOAP

•  For some bindings •  Wire overhead, processing

overhead, compatibility

•  XML •  Semantics: Interoperable syntax

doesn’t mean interoperable semantics

•  Options…

Deployment


Bindings (1) – SAML Redirect & POST


Frontchannel only •  One step, by value •  Popular (95%): easy (firewall), no

SP authentication •  For Requests and Responses (not

redirect: size, logs) •  User Agent sees messages

•  Unless encrypted

Consumer Producer

Browser

1

Bindings (2) – SAML Artifact


Backchannel •  Two steps, by reference •  Pass reference through

frontchannel, get message through backchannel

•  Authentication of sender on backchannel! (cert mgmt)

•  For Requests (rare) and (large) Responses

•  (Perceived?) security

Consumer Producer

Browser

2

1

IDP initiated SSO


Characteristics •  Assumes a starting point at the

IDP •  Enterprise portal/intranet

•  Implementation dependent trigger •  RelayState

•  De-facto agreement

•  Potential open redirect

•  Deeplinks •  dependency on SP changes

SP IDP

Browser

1

SP initiated SSO


Characteristics •  Start at the SP •  In some way a superset of IDP-

init-SSO •  Static implementation

independent links •  (Perceived?) overhead over SP-

init-SSO •  roundtrip

•  Need to find out about the IDP

SP IDP

Browser

2

1

Features


Miscellaneous •  Signed Authentication Requests

•  Why? Shift to SP init process •  DoS prevention…? Depends

•  Encrypted Assertions •  SSL, user

•  Session Management •  Application session != IDP

session

Deployment Profile (1)


Characteristics •  Differs from Implementation Profile

(!), “what can you rely on” •  Options, Bindings, Attributes, LoA/

authncontext, forceAuthn, isPassive, User Consent

•  Examples: •  E-Gov x1000 for each

government… #$#%!%, FICAM, IDAP, e-Recognition…

•  SAML2Int, v0.2, Higher Ed & Research

Deployment Profile (2): SAML2Int


saml2int.org •  AuthNRequest – HTTP-Redirect,

AuthNResponse – HTTP POST (yay!)

•  Metadata MUST, technical contact

•  Attribute format (“uri”), Name identifiers (transient MUST)

•  No encryption, Etc.

Advanced Topics… and (==?) Pitfalls


IDP Discovery (1)


Issues •  Inconvenience for users

•  But only the first time (in non-kiosk scenario’s)

•  Often perceived as inhibitor for SSO

•  “Ask User” is best common practice

•  “intelligent” approaches •  Typically work well except for

edge cases (roaming users)… •  Ok, not specific to SAML but

WHERE ARE YOU

FROM?

IDP Discovery (2)


Solutions •  Enterprise: IDP init SSO from a

corporate portal… •  NASCAR

•  Consumer OK •  Enterprise: list/phish customers

•  Domain scoped usernames •  “wayf-less” URLs (nice for deeplinks)

•  Domain/vhost •  URL path

•  Header, CIDR •  Account Chooser

Non-Browser Clients


Enhanced Client or Proxy (ECP) •  Rich Clients, Desktop Clients,

Native Mobile Apps (!) •  Adoption…, Interoperability… •  O365

Single Logout


Frontchannel or Backchannel •  The nature of the web…

•  User needs to inspect and accept results

•  SSO != SLO •  Inconvenience vs. insecurity

•  Attempt to increase security leads to decreased security…

•  “if you think you understand SLO you probably don’t”

Trust


Have YOU thought about it? •  Probably needs an SLA and/or

policy (depending on who pays) •  SP: privacy •  IDP: accuracy

•  Multi-lateral federation, frameworks

SAML 2.0 Metadata


Federation Partner: “Identity” •  Optional.. but •  Source of trust

•  How did you receive it? •  How do you update it? •  Valid-Until/Cache-Duration

•  Certificate (format) in metadata is (usually) for key representation only (!), expiry (?)

•  XML, Extensions… •  Deployment Profile

Signing and Verification


The Core Piece •  XMLDSig: signature is embedded

in XML, not detached •  Need to process XML and

canonicalize •  Heavyweight, DoS sensitive •  Many different options, some of

them have become insecure •  Sign response vs. assertion

Certificate Rollover


Synchronization •  THE biggest problem

•  Initial setup effort vs. maintenance effort (forget)

•  Synchronization •  We can/should do better

•  Use the same keypair for a new cert! •  May work, may defeat the

purpose (compromised key)

•  Multiple certs in metadata: support

Scalability


Issues •  SAML is point to point •  Scalability of Trust

•  Metadata exchange •  Proxy

•  Scalability of attribute naming •  Adoption of interop/deployment

profile(s)

Bridging


Bridge / Proxy / Hub / Router •  Real sender/receiver info is lost

•  Invisible across the bridge •  SAML requests have issuer, no

audience/recipient •  Audience embedded in SSO URL

•  Query/path •  Protocol translation •  IDPProxy SAML element •  Trust (!)

IDP SP

IDP SP

IDP SP

Proxy

SP IDP

Failures


A (Small) Selection •  SP branded login screen

•  NOOO, IDP branding!! for security •  simpleSAMLphp demo cert… •  NO signature validation… •  Grep as XML parser… •  No replay prevention (toolkits) •  XML signature wrapping attack

•  Code maintenance! •  SAML assertion = password

•  Send somewhere else, impersonate, etc.

•  Multiple assertions •  Support… API: how is it represented

to the receiver…?

Successes


Inclusive… •  Federation: standards based cross-

domain SSO •  Single point of control back in

enterprise domain •  Shadow IT

•  Single point of authentication •  More than SSO •  No password proliferation •  Upgrade to strong authn

•  It is there

Future


Directions •  “SAML is dead” •  Multi-party federation through

trusted 3rd party •  Proxy •  Metadata service, distribution

•  Bridge to OpenID Connect •  SAML 2.1?

Recommendations


Stick with the ordinary… •  Stable but only 5% is used,

adoption/success is moderate, no development -> OIDC

•  Still some pitfalls to consider •  DON’T READ THE SPEC AND

ASSUME THAT YOUR PEERS INTERPRETED IT IN THE SAME WAY (OR EVEN READ IT…)

•  BCP: SAML2INT


Thank You

Hans Zandbelt [email protected]

Twitter: @hanszandbelt

Technology

CIS 2015 Extreme SAML - Hans Zandbelt