saml-v1_x-tech-overview-dec051 Security Assertion Markup Language SAML 1.x Technical Overview Tom Scavo NCSA

saml-v1_x-tech-overview-dec052 SAML 1.0

saml-v1_x-tech-overview-dec053 SAML 1.0 SAML 1.0 was adopted as an OASIS standard in Nov 2002 SAML has undergone one minor (V1.1) and one major (V2.0) revision since V1.0 SAML 1.0 Interestingly, the Fed E- Authentication Initiative has adopted SAML 1.0 as its core technologyE- Authentication Initiative

saml-v1_x-tech-overview-dec054 E-Authentication The E-Authentication Initiative publishes standards and tests implementations: Currently, the E-Auth Interop Lab tests vendor products for compatibility with the SAML 1.0 Browser/Artifact Profile Some form of SAML 2.0 compatibility testing is expected to begin soon

saml-v1_x-tech-overview-dec055 SAML 1.0 and 1.1 Diffs Versions 1.0 and 1.1 of SAML are similar: Differences between OASIS Security Assertion Markup Language (SAML) V1.1 and V1.0 Differences between OASIS Security Assertion Markup Language (SAML) V1.1 and V1.0 In what follows, we concentrate on SAML 1.1 since it is the definitive standard Currently, most other standards and implementations depend on SAML 1.1

saml-v1_x-tech-overview-dec056 SAML 1.1 Basics

saml-v1_x-tech-overview-dec057 SAML 1.1 SAML 1.1 was ratified as an OASIS standard in Sep 2003 SAML 1.1 is the definitive standard underlying many web browser SSO solutions in the identity management problem space Other important use cases besides browser SSO have emerged

saml-v1_x-tech-overview-dec058 SAML 1.1 Specifications Assertions and Protocol Bindings and Profiles Security and Privacy Considerations Conformance Program Specification Glossary

saml-v1_x-tech-overview-dec059 SAML 1.1 Schema SAML uses XML Schema as the specification language Assertion Schema Protocol Schema Namespace prefixes: –xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" –xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"

saml-v1_x-tech-overview-dec0510 SAML 1.1 Use Cases As specified, SAML 1.1 use cases are –strictly browser-based –IdP-first Other use cases have been developed outside the OASIS TC, including: –WS-Security SAML Token Profile –Liberty ID-FF –Globus Toolkit Authz callout

saml-v1_x-tech-overview-dec0511 SAML 1.1 Core

saml-v1_x-tech-overview-dec0512 SAML 1.1 Assertions SAML assertions are transferred from identity providers to service providers Assertions contain statements that SPs use to make access control decisions Three types of statements are specified by SAML: 1.Authentication statements 2.Attribute statements 3.Authorization decision statements

saml-v1_x-tech-overview-dec0513 Assertion Example A typical SAML 1.1 assertion stub: The value of the Issuer attribute is the unique identifier of the IdP

saml-v1_x-tech-overview-dec0514 SAML 1.1 Statements SAML 1.1 statement syntax: –

saml-v1_x-tech-overview-dec0515 Authentication Assertions An authentication assertion contains a subject-based authentication statement: urn:oasis:names:tc:SAML:1.0:cm:artifact This form is used in the Browser/Artifact Profile

saml-v1_x-tech-overview-dec0516 Authentication Assertions (cont’d) The following authn statement preserves privacy: 3f7b3dcf ecd-92c8-1544f346baf8 urn:oasis:names:tc:SAML:1.0:cm:bearer This form might be used in the Browser/POST Profile

saml-v1_x-tech-overview-dec0517 Authentication Method SAML 1.1 specifies numerous (11) AuthenticationMethod identifiers: urn:oasis:names:tc:SAML:1.0:am:password urn:ietf:rfc:1510 (i.e., Kerberos) urn:oasis:names:tc:SAML:1.0:am:X509-PKI urn:oasis:names:tc:SAML:1.0:am:unspecified etc. These identifiers describe (to an SP) an authentication act that occurred in the past SAML2 extends this notion…

saml-v1_x-tech-overview-dec0518 Attribute Assertions An attribute assertion contains an attribute statement: 3f7b3dcf ecd-92c8-1544f346baf8 faculty No SAML 1.1 attribute profiles exist

saml-v1_x-tech-overview-dec0519 Authorization Decision Assertions An authorization decision assertion contains an authorization decision statement Authorization decisions are out of scope in a typical SAML deployment An interesting use case is the grid- based authz callout:

saml-v1_x-tech-overview-dec0520 Hybrid Assertions A single assertion may include multiple statements Multiple authentication statements and/or attribute statements are permitted (use cases?) A single assertion may include both authentication and attribute statements

saml-v1_x-tech-overview-dec0521 SAML Subject In a statement, the SAML Subject is important: … In this example, the Format of the NameIdentifier is an Address, a transparent, persistent identifier In deployments where privacy is an issue, an opaque, transient identifier is more appropriate Unfortunately, SAML 1.1 does not specify such an identifier

saml-v1_x-tech-overview-dec0522 SAML Protocol Two protocol flows: push and pull In the pull case, the SP initiates the exchange by first sending a query to the IdP The query is wrapped in a element The IdP responds with a SAML assertion wrapped in a element Alternatively, the response is pushed from the IdP to the SP by the browser user

saml-v1_x-tech-overview-dec0523 SAML 1.1 Response A basic SAML Response element: In the pull case, the response is preceded by a request

saml-v1_x-tech-overview-dec0524 SAML 1.1 Request Similarly, a SAML Request element: There are a handful of specified SAML queries and a couple of extension points to construct your own

saml-v1_x-tech-overview-dec0525 SAML 1.1 Queries An SP queries for assertions with: – There is also an abstract extension point for arbitrary subject-based queries: – A totally general abstract extension point: –

saml-v1_x-tech-overview-dec0526 SAML 1.1 Queries (cont’d) Of all the queries, is most used On the other hand, is least used since authn assertions are usually pushed Two other query elements are specified: – The latter is used in the Browser/Artifact profile

saml-v1_x-tech-overview-dec0527 SAML 1.1 Bindings and Profiles

saml-v1_x-tech-overview-dec0528 SAML 1.1 Bindings SAML 1.1 specifies just one binding (but allows others) The SAML SOAP Binding specifies SOAP 1.1 Only the SOAP body is used by SAML Use of SOAP over HTTP is specified (but other substrates are not precluded)

saml-v1_x-tech-overview-dec0529 SAML 1.1 Profiles SAML 1.1 specifies two profiles: –Browser/POST Profile –Browser/Artifact Profile These browser profiles are cross- domain single sign-on (SSO) profiles No other profiles are specified in this version of SAML

saml-v1_x-tech-overview-dec0530 SAML 1.1 SSO Profiles SAML SSO profiles are browser-based –Other uses of SAML are not specified SAML Browser/POST Profile –Authentication assertion by value (push) SAML Browser/Artifact Profile –Authentication assertion by reference (pull) Both SAML profiles are IdP-first –Details follow

saml-v1_x-tech-overview-dec0531 Browser/POST Profile The client hand- carries an authentication assertion from the IdP to SP We assume the client has already authenticated and possesses a security context at the IdP Identity Provider Service Provider CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 1 The user requests the Inter-site Transfer Service at the IdP The GET request includes a TARGET parameter Assume a security context already exists (out of scope) CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec0533 Browser/POST Step 1 The browser user requests the Inter-site Transfer Service at the IdP: The TARGET value is the location of the desired resource at the SP SAML does not specify how the URL to the Transfer Service is obtained Presumably, the user authenticates into a portal at the IdP

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 2 The IdP responds with an HTML form The form contains a TARGET element (from the request) and a SAMLResponse element The value of the SAMLResponse element is the base64 encoding of a SAML Response CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec0535 Browser/POST Step 2 The Transfer Service returns an HTML FORM:... The SAMLResponse value is the base64 encoding of a SAML Response element The SAML Response must be digitally signed by the IdP

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 3 The user POSTs the form to the Assertion Consumer Service at the SP The request includes TARGET and SAMLResponse parameters from the form CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec0537 Browser/POST Step 3 The client issues a POST request to the Assertion Consumer Service at the SP JavaScript may be used to automate the submission of the form: window.onload = function () {document.forms[0].submit();} A submit button is provided in case the JavaScript fails

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 4 The Assertion Consumer Service validates the signature on the SAML Response and creates a security context at the SP The SP redirects the client to the target resource CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 5 The client requests the desired resource The resource is protected, that is, only clients with an appropriate security context are allowed CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/POST Step 6 Since the client possesses the necessary security context, access is allowed The requested resource is returned to the client CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource

saml-v1_x-tech-overview-dec0541 IdP-first vs. SP-first If the client requests the resource without a corresponding security context, access will be denied The SAML 1.1 browser profiles are IdP- first for simplicity SP-first profiles introduce some complex issues (such as IdP Discovery)

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Profile In this case, the IdP chooses to issue an artifact in lieu of an actual authentication assertion Again, we assume the client possesses the necessary security context at the IdP CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 1 The user requests the Inter-site Transfer Service at the IdP If necessary, the IdP identifies the user (out of scope) The GET request includes a TARGET parameter CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 2 The IdP redirects to the Assertion Consumer Service The redirect URL includes the TARGET parameter and a SAMLart parameter The artifact is a reference to an authN assertion CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec0545 Browser/Artifact Step 1–2 Step 1 is identical to Browser/POST step 1 At step 2, the client is redirected to the Assertion Consumer Service at the SP: HTTP/ Found Location: target&SAMLart=artifact The SAMLart value is an opaque reference to an assertion the IdP is willing to provide upon request

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 3 The user requests the Assertion Consumer Service at the SP The request includes the TARGET and SAMLart parameters CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec0547 Browser/Artifact Step 3 The client requests the Assertion Consumer Service at the SP: ARGET=target&SAMLart=artifact An artifact encodes the following data: –2-byte type code –20-byte SourceID (usually IdP providerId) –20-byte AssertionHandle Two artifact types are specified

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 4 The SP requests the Artifact Resolution Service at the IdP via a mutually authenticated, back-channel exchange The SAML SOAP request includes the artifact CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec0549 Browser/Artifact Step 4 The SP initiates a back-channel exchange with the Artifact Resolution Service at the IdP The following SAML query is bound to a SAML SOAP request: artifact The artifact value was obtained from client previously

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 5 The IdP returns a SAML Response to the SP The SAML Response contains an authentication assertion CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 6 The Assertion Consumer Service validates the SAML Response element and creates a security context at the SP The SP redirects the client to the target resource CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec0552 Browser/Artifact Step 5–6 The identity provider completes the back-channel exchange by responding with a SAML assertion The assertion is similar to the one pushed by the client in Browser/POST (but without the signature) Step 6 is identical to Browser/POST step 4

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 7 The client requests the protected resource This step is identical to Browser/POST step 5 CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec Identity Provider Service Provider Browser/Artifact Step 8 The requested resource is returned to the client This step is identical to Browser/POST step 6 CLIENTCLIENT Authentication Authority Attribute Authority Inter-site Transfer Service Assertion Consumer Service Resource Artifact Resolution Service

saml-v1_x-tech-overview-dec0555 SAML Security The security implications of the SAML artifact profile have been critically examined: services/200406/msg00087.html services/200406/msg00087.html The Security Services TC has responded: open.org/committees/download.php/1363 9/sstc-gross-sec-analysis-response-cd- 01.pdf open.org/committees/download.php/1363 9/sstc-gross-sec-analysis-response-cd- 01.pdf

saml-v1_x-tech-overview-dec0556 Misc

saml-v1_x-tech-overview-dec0557 Liberty Implementations Implementations of Liberty ID-FF: –SourceID ID-FF 1.2 Java Toolkit –Lasso –Proprietary vendor implementations Liberty ID-FF 1.2 is based on SAML 1.1 Since ID-FF was “donated” to OASIS SAML, it is fair to say that ID-FF is a terminal specification