Security Assertion Markup Language (SAML)

1. Security Assertion Markup Language (SAML) RL "Bob" Morgan, University of Washington

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

3. SAML in one slide Security Assertion Markup Language • specification from OASIS Security Services TC • supports interop among "web access management" products and deployments • supports "async" and B2B processes too • defines Assertions in XML for carrying Authentication, Attribute, Authz Decision statements • defines simple XML request/response protocol that runs over SOAP (or HTTP or other) • could be security format for other XML protocols

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

5. 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 of participants: • "distributed systems security" (i.e., DCE) • PKI • XML (SOAP, schema definition, web services)

6. 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

7. SAML scope/structure XML-format Assertions as fundamental tech • used for core authn/authz purposes • exchange of security info between systems/domains • also extensible for other XML-based assertions • e.g. OASIS XACML (ACLs in XML, sort of) TC Protocol as simple means to get Assertions • runs over existing "transports" eg SOAP Profiles specify use in application scenarios • e.g., web browser sign-on scenario

8. SAML Domain Model

9. 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

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

11. 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

12. Bindings Specify transport of protocol messages in carrier protocols • SOAP is mandatory-to-implement • HTTP, BEEP are possible • S/MIME also mentioned early, but not specified • protection via SSL in binding may avoid use of signature on assertion/message

13. Browser profile Supports the standard web sign-on case • user initial authentication not in scope, session management also left for later 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 Or: use HTTP POST to send full assertion Both methods will be specified

14. Other SAML spec docs Conformance • specify mandatory-to-implement functions • requirements for particular app scenarios Security/Privacy considerations • describes threats and mechanisms,implementation concerns • Shibboleth privacy concerns will go here

15. SAML Status First meeting Jan 9, 2001 "Core" document mostly done (rev 22 now) • includes assertion and protocol schema Profile/bindings more or less done (rev 8) Conformance, sec/priv docs getting closer Initiating public review this week, hoping for "last call" Feb 1 Netegrity released open toolkit in October

16. 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

17. What about Microsoft? MS didn't participate in early work,but received some "encouragement" later Has contributed Kerberos design ideas • subcommittee to pursue this more hasn't happened Latest .NET/Passport story addresses "federated" functions, based on Kerberos No commitment to SAML apparent Will MS open authorization data format?

18. 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

19. 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 is based on SAML