Security Assertion Markup Language (SAML)

1. Security Assertion Markup Language (SAML) A Progress Report Hal Lockhart hal.lockhart@entegrity.com

2. Agenda • The problem space • Why invent SAML at all? • What are the use cases that drive SAML’s design? • SAML concepts • Status of SAML and related standards efforts • Interoperability Demonstration • SAML Futures

3. What is SAML for? • Distributed Authorization • Federated Identity Management • Multi-vendor Portals • Web Services Access Control

4. SAML Use Cases • SAML developed three “use cases” to drive its requirements and design: • Single sign-on (SSO) • Distributed transaction • Authorization service • Each use case has one or more “scenarios” that provide a more detailed roadmap of interaction

5. Authenticate Source Web Site Use Secured Resource Web User Destination Web Site #1: Single sign-on (SSO) • Logged-in users of analyst research site SmithCo are allowed access to research produced by sister site JonesCo

6. Authenticate, Qualify Authority Known to Both Transact Business Buyer Seller #2: Distributed transaction • Employees at SmithCo are allowed to order office supplies from OfficeBarn if they are authorized to spend enough

7. Policy Decision Point Check Permission Access Resource User Policy Enforcement Point #3: Authorization service • Employees at SmithCo order office supplies directly from OfficeBarn, which performs its own authorization

8. Policy Policy Policy Credentials Authentication Attribute Policy Decision Collector Authority Authority Point Application System Policy Enforcement Request Entity Point SAML producer-consumer model

9. SAML Specification Elements • A standard XML message format • It’s just data traveling on any wire • No particular API mandated • Lots of XML tools available • A standard message exchange protocol • Clarity in orchestrating how you ask for and get the information you need • Rules for how the messages ride “on” and “in” transport protocols • For better interoperability

10. SAML is NOT… • A new form of Authentication • Existing security “translated” into XML • An alternative to WS-Security • Limited to legacy applications • Limited to Web Browser applications • Limited to Web Services security

11. SAML assertions • Assertions are declarations of fact, according to someone • SAML assertions are compounds of one or more of three kinds of “statement” about “subject” (human or program): • Authentication • Attribute • Authorization decision • You can extend SAML to make your own kinds of assertions and statements • Assertions can be digitally signed

12. Asserting Party Relying Party SAML protocol for getting assertions

13. SAML Bindings and Profiles • This is where SAML itself gets made secure • A “binding” is a way to transport SAML requests and responses • SOAP-over-HTTP binding is a baseline • Other bindings will follow, e.g., raw HTTP • A “profile” is a pattern for how to make assertions about other information • Two browser profiles for SSO: artifact and POST • WS-Security profile for securing SOAP payloads

14. The SOAP-over-HTTP binding Transport (HTTP) SOAP Message SOAP Header SOAP Body SAML Request or Response

15. SAML Web Services Profile Transport (HTTP) SOAP Message SOAP Header SAML Assertion about SOAP Body SOAP Body ...

16. SAML status • Work started on 9 January 2001 • From a base of S2ML and AuthXML • www.oasis-open.org/committees/security/ • TC voted to accept as Committee Specification on 16 April 2002 • Submitted to OASIS for Approval – 28 May 2002 • Approval expected 1 Nov 2002 • More that a dozen vendors have announced implementations – most soon in products • Public Interoperability Demonstration • Catalyst Conference – 15 July 2002

17. SAML Interoperability Demo • 12 Vendors Participated • Baltimore Technologies, Crosslogix, ePeople, Entegrity Solutions, IBM/Tivoli, Netegrity, Novell, Oblix, OverXeer, RSA Security, Sigaba, Sun Microsystems • 9 Portals • 12 Applications • SAML Browser/Artifact Profile • Dry runs June 17-21 • Setup and Testing - July 13 & 14 • Demonstration and Press Conference – July 15 • Remarkably easy for first use of a specification

18. Application 1 Application 2 Application 3 Application 4 Interoperability Demo Elements Application 1 Portal Application 2 username password Application 3 Application 4

19. Authenticate Source Web Site Use Secured Resource Web User Destination Web Site Demonstration Scenario • Begin demo: signon at any Portal • Click thru to any application • Service depends on user attributes

20. Authenticate (out of band) Access inter-site transfer URL Redirect with artifact Get assertion consumer URL Request referenced assertion Supply referenced assertion Provide or refuse destination resource (out of band) Demo Message Exchange Portal Application Source Destination Web User Web Site Web Site

21. SAML Futures • Web Services Profile • SAML Attribute Assertion in SOAP header • In committee draft • XML Encryption Profile • XML encryption was not mature last year – now it is • Credentials Collector (Proxy Login) • Dynamic Sessions • XACML enhancements • Other enhancements – Delegation?

22. Questions?