October 2, 2001 SAML RL "Bob" Morgan, University of Washington

Topics How it came to be SAML scope SAML architecture Status Issues

SAML in one slide Security Assertion Markup Language •specification from OASIS Security Services TC •supports interop among "web access management" products and deployments; other functions too •defines Assertions in XML for carrying Authentication, Attribute, Authz Decision statements •defines simple XML request/response protocol •bindings to common transports: HTTP, SOAP •could be security syntax for other XML-based protocols

How it came to be "Web access management" products •webiso-like services, plus authz management •many vendors in market, in deployments, customers want interop •other opportunities for XML-based stuff (eg ebXML-defined business processes) 2000: vendors struggle, decide to cooperate •Jan 2001 establish committee in OASIS, a membership org promoting XML-based standards

Who are the players Netegrity, Securant (now RSA) contributed initial specs (S2ML, AuthXML) Other major vendors/contributors: •Baltimore, Entrust, Entegrity, HP, IBM/Tivoli, Oblix, Sun, VeriSign, Jamcracker, others (and Internet2!) Areas of expertise: •"distributed systems" (i.e., DCE) •PKI •XML (SOAP, schema definition, web services)

What the major products do Web single sign-on •multiple backend mechanisms, etc. •redirect model vs proxy model Authorization management for web apps •"policy store" with rules, expressions, attributes •access protocol from webserver to policy engine – can user foo see page X? Session management •single sign-off, single time-out

SAML scope/structure XML-format Assertions as fundamental tech •used for core authn/authz purposes •exchange of security info between systems/domains •also reusable for other XML-based assertions –e.g. OASIS XACML (ACLs in XML, sort of) TC Bindings are where "security" lives •e.g., protection with SSL or XML-DSIG Profiles specify use in application scenarios •e.g., web browser sign-on scenario

SAML Domain Model

SAML Assertions Authentication •statement that Subject authenticated at time T •authentication exchange itself is not in SAML scope Attribute •statement that Subject has stated attributes –presumably but not necessarily "authorization" attrs Authorization Decision •statement that resource request is granted/denied

Assertion basics Each Assertion has: •Assertion ID •Subject –optional SubjectConfirmation, e.g. public key –NameIdentifier = Name + SecurityDomain •IssueInstant •Issuer (string) •Conditions: critical (i.e., "must process") elements •Advice: other non-critical items

Request/response protocol Simplest possible protocol for requesting/supplying any kind of assertion •not intended to rival SQL, LDAP, etc Authentication, Attribute Assertions are requested for a particular Subject Authz Decision Assertion request is: •is action Y on resource Z by subject S permitted? This protocol is not the only way to get Assns

Bindings Specify transport of protocol messages in carrier protocols •HTTP, HTTP/SSL, SOAP are most likely •BEEP is possible •S/MIME also desirable •protecting via XML-DSIG part of binding spec?

Browser profile Supports the standard web sign-on case Size limits of URLs, cookies a problem •"Artifact" refers to an assertion, is small enough to travel in URL/cookie •used by receiver to request full (authn) assertion Alternative: use POST to send full assertion Both methods will be specified, probably Concern: where do "countermeasures" go?

Other SAML spec docs Conformance •specify mandatory-to-implement pieces •may profile particular app scenarios Security/Privacy considerations •will depend a lot on specifics of bindings, schema •most Shibboleth privacy concerns go here

SAML Status "Core" document mostly done (rev 19 now) •includes assertion and protocol schema Browser profile mostly done (rev 5) Other bindings need more work Conformance, sec/priv considerations still early in process Intent to have spec by December 2001 Netegrity releasing open toolkit in October

Issues and observations A lot is still left to designers/deployers •Is Subject NameIdentifier a DN, a Kerb name? –It's a string! Whatever! –same with Issuer! •out-of-box interop is unlikely XML Schema-writing is still a young art •differences of opinion on best practice •unknown value of some constructs, as still not supported in parsers or common in practice Remarkable collaboration among worldviews

What about Microsoft? MS didn't participate in early work, but received some "encouragement" later Has contributed design ideas, mostly about Kerberos support •subcommittee formed to pursue this more Latest.NET/Passport story addresses "federated" functions, based on Kerberos No commitment to SAML, but at the table Authorization data format interop?

More speculation SAML vs. X.509? •X.509 certs underlie authentication, SSL, DSIG •Authn Assns are somewhat like PK certs •Attr Assns are very much like X.509 Attr certs •still disjunction between ASN.1 and XML (really, ASN.1 "schema" vs XML Schema) SAML vs Kerberos? •Authn Assn like session ticket •Kerberos fine as binding/transport, once specified •Kerberos per se has no authz data format

Conclusion SAML meets important interop requirements Right players are involved Spec is moving along, software happening Will be important technology Won't solve problems out of the box Shibboleth based on SAML