Security Assertion Markup Language

1
Security Assertion Markup Language

• Tom Scavo
• NCSA

2
Overview

• SAML assertions and statements
• SAML request/response protocol
• SAML bindings (e.g., SOAP binding)
• SAML profiles, especially browser profiles
• SAML attribute exchange
• Coverage of both SAML 1.x and 2.0
• Detailed examples (code and flows)

3
SAML

• Security Assertion Markup Language (SAML) is an
  XML standard for exchanging authentication and
  authorization data between entities
• SAML is a product of the OASIS Security Services
  Technical Committeehttp//www.oasis-open.org/com
  mittees/security/

4
SAML Specification

• A SAML specification includes
• Assertions (XML)
• Protocols (XML)
• Bindings (HTTP, SOAP)
• Profiles ( Protocols Bindings)
• Assertions and protocols together constitute SAML
  core (syntactically defined in XML schema)

5
SAML Standards

• SAML is built upon the following technology
  standards
• Hypertext Transfer Protocol (HTTP)
• Extensible Markup Language (XML)
• SOAP
• XML Schema
• XML Signature
• XML Encryption (SAML 2.0 only)

6
SAML Use Cases

• The most important problem that SAML is trying to
  solve is the web single sign-on (SSO) problem
• Browser-based SSO
• Liberty ID-FF
• Shibboleth
• A host of vendor products
• Web services security
• WS-Security SAML Token Profile
• Liberty ID-WSF
• Authorization and access control
• Globus Tookit Authz callout
• SAML 2.0 Profile of XACML
• GridShib

7
SAML Security

• The security implications of the SAML artifact
  profile have been critically examinedhttp//list
  s.oasis-open.org/archives/security-services/200406
  /msg00087.html
• The SAML specs recommend a variety of security
  mechanisms including
• Transport-level security (SSL 3.0/TLS 1.0)
• Message-level security (XMLSig/XMLEnc)
• Requirements phrased in terms of (mutual)
  authentication, integrity and confidentiality,
  leaving details to the implementers

8
SAML Terminology

• SAML 2.0 terminology used throughout
• Identity Provider (IdP)
• Authentication Authority
• Single Sign-On Service
• Artifact Resolution Service
• Attribute Authority
• Service Provider (SP)
• Assertion Consumer Service
• Attribute Requester
• Artifact Resolution Service (SAML 2.0 only)

9
XML Namespaces

• In SAML1, the prefixes saml and samlp stand for
  the assertion and protocol namespaces,
  respectivelyurnoasisnamestcSAML1.0assertio
  nurnoasisnamestcSAML1.0protocol
• In SAML2, the namespaces are similarurnoasisna
  mestcSAML2.0assertionurnoasisnamestcSAML
  2.0protocol
• The SAML2 metadata prefix md refers to
  urnoasisnamestcSAML2.0metadata

10
SAML 1.0
11
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
• Interestingly, the Fed E-Authentication
  Initiative has adopted SAML 1.0 as its core
  technology

12
E-Authentication

• The E-Authentication Initiative publishes
  standards and tests implementationshttp//www.ci
  o.gov/eauthentication/
• 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

13
SAML 1.0 and 1.1 Diffs

• Versions 1.0 and 1.1 of SAML are
  similarDifferences between OASIS Security
  Assertion Markup Language (SAML) V1.1 and V1.0
• In what follows, we concentrates on SAML 1.1
  since it is the definitive standard
• Currently, most other standards and
  implementations depend on SAML 1.1

14
SAML 1.1
15
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

16
SAML 1.1 Use Cases

• As specified, SAML 1.1 use cases are strictly
  browser-based
• Other use cases have been developed outside the
  OASIS TC, including
• WS-Security SAML Token Profile
• Liberty ID-FF
• Globus Toolkit Authz callout

17
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
• Authentication statements
• Attribute statements
• Authorization decision statements

18
Assertion Example

• A typical SAML 1.1 assertion stub xmlnssaml"urnoasisnamestcSAML1.0asserti
  on" MajorVersion"1" MinorVersion"1"
  AssertionID"a75adf55-01d7-40cc-929f-dbd8372ebdfc"
  IssueInstant"2004-12-05T092202Z"
  Issuer"https//idp.org/shibboleth"
  02Z" NotOnOrAfter"2004-12-05T092702Z"/
  
• The value of the Issuer attribute is the unique
  identifier of the IdP

19
Authentication Assertions

• An authentication assertion contains a
  subject-based authentication statemententicationStatement AuthenticationInstant"2004-
  12-05T092200Z" AuthenticationMethod"urnoasis
  namestcSAML1.0ampassword"
  Format"urnoasisnamestcSAML1.1nameid-format
  emailAddress" NameQualifier"https//idp.org
  /shibboleth" user_at_mail.idp.org
  on
  urnoasisnamestcSAML1.0cmartifact
  rmation atement
• This form might be used in the Browser/Artifact
  Profile

20
Authentication Assertions (contd)

• The following authn statement preserves
  privacyAuthenticationInstant"2004-12-05T092200Z
  AuthenticationMethod"urnoasisnamestcSAML1.0
  ampassword"
  oleth1.0nameIdentifier
  NameQualifier"https//idp.org/shibboleth"
  3f7b3dcf-1674-4ecd-92c8-1544f346baf8
  on
  urnoasisnamestcSAML1.0cmbearer
  rmation atement
• This form might be used in the Browser/POST
  Profile

21
Authentication Method

• SAML 1.1 specifies numerous (11)
  AuthenticationMethod identifiersurnoasisnames
  tcSAML1.0ampasswordurnietfrfc1510 (i.e.,
  Kerberos)urnoasisnamestcSAML1.0amX509-PKI
  urnoasisnamestcSAML1.0amunspecifiedetc.
• These identifiers describe (to an SP) an
  authentication act that occurred in the past
• SAML2 extends this notion

22
Attribute Assertions

• An attribute assertion contains an attribute
  statement
  Format"urnmaceshibboleth1.0nameIdentifier"
  NameQualifier"https//idp.org/shibboleth"
  3f7b3dcf-1674-4ecd-92c8-1544f346baf8
  
  ttribute-defeduPersonAffiliation"
  AttributeNamespace"urnmaceshibboleth1.0attrib
  uteNamespaceuri"
  faculty
  
• No SAML 1.1 attribute profiles exist

23
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
  callouthttp//users.sdsc.edu/chandras/Papers/cc
  grid-submission.pdf

24
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

25
SAML 1.1 Response

• A basic SAML Response elementxmlnssamlp"urnoasisnamestcSAML1.0protocol"
  InResponseTo"aaf23196-1773-2113-474a-fe114412a
  b72" IssueInstant"2004-12-05T092205Z"
  MajorVersion"1" MinorVersion"1"
  ResponseID"b07b804c-7c29-ea16-7300-4f3d6f7928ac"
  Value"samlpSuccess"/
• In the pull case, the response is preceded by a
  request

26
SAML 1.1 Request

• Similarly, a SAML Request element xmlnssaml"urnoasisnamestcSAML1.0assertio
  n" xmlnssamlp"urnoasisnamestcSAML1.0prot
  ocol" MajorVersion"1" MinorVersion"1"
  IssueInstant"2004-12-05T092204Z"
  RequestID"aaf23196-1773-2113-474a-fe114412ab72"
  
  
• There are a handful of specified SAML queries and
  a couple of extension points to construct your own

27
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

28
SAML 1.1 Queries (contd)

• 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

29
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)

30
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

31
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

32
Browser/POST Profile

• The SAML 1.1 Browser/POST Profile consists of
  four steps
• Request the Inter-site Transfer Service IdP
• Respond with an HTML form
• Request the Assertion Consumer Service SP
• Respond to the clients request
• The following slides give the details

33
Browser/POST Step 1

• The browser user requests the Inter-site Transfer
  Service at the IdPhttps//idp.org/TransferServic
  e?TARGETtarget
• 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

34
Browser/POST Step 2

• The Transfer Service returns an HTML FORMmethod"post" action"https//sp.org/ACS/po
  st" ... value"target" / name"SAMLResponse"
  value"response" / ...
• The SAMLResponse value is the base64 encoding of
  a SAML Response element
• The SAML Response must be digitally signed by the
  IdP

35
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 formwindow.onload function ()
  document.forms0.submit()
• A submit button is provided in case the
  JavaScript fails

36
Browser/POST Step 4

• The Assertion Consumer Service validates the SAML
  Response element
• A security context is created at the SP
• The following three substeps occur
• Redirect the client to the target resource
• Request the target resource SP
• Respond with the requested resource

37
Browser/Artifact Profile

• The SAML 1.1 Browser/Artifact Profile consists of
  six steps
• Request the Inter-site Transfer Service IdP
• Redirect to the Assertion Consumer Service
• Request the Assertion Consumer Service SP
• Request the Artifact Resolution Service IdP
• Respond with a SAML Assertion
• Respond to the clients request
• Steps 1 and 6 are identical to Browser/POST

38
Browser/Artifact Step 12

• Step 1 is identical to Browser/POST step 1
• At step 2, the client is redirected to the
  Assertion Consumer Service at the SPHTTP/1.1
  302 FoundLocation https//sp.org/ACS/Artifact?TA
  RGETtargetSAMLartartifact
• The SAMLart value is an opaque reference to an
  assertion the IdP is willing to provide upon
  request

39
Browser/Artifact Step 3

• The client requests the Assertion Consumer
  Service at the SPhttps//sp.org/ACS/Artifact?TAR
  GETtargetSAMLartartifact
• An artifact encodes the following data
• 2-byte type code
• 20-byte SourceID (usually IdP providerId)
• 20-byte AssertionHandle
• Two artifact types are specified

40
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

41
Browser/Artifact Step 56

• 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

42
SAML 1.1 Toolkits

• Implementations of SAML 1.1 core
• OpenSAML 1.0.1 (Java/C)http//www.opensaml.org/
  
• SourceID SAML 1.1 Java Toolkit 2.0http//www.sour
  ceid.org/projects/saml-1.1-toolkit.html
• SAMUEL (Java)http//sourceforge.net/projects/guan
  xi/
• Proprietary vendor implementations
• OpenSAML and SourceID have announced SAML 2.0
  toolkits by Dec 2005 and summer 2005,
  respectively, but full 2.0 compatibility is a
  long way off

43
SAML 1.1 Implementations

• Implementations of SAML 1.1 profiles
• Shibboleth 1.3http//shibboleth.internet2.edu/
• Proprietary vendor implementations
• Shibboleth is the only known open source
  implementation of the SAML 1.1 browser profiles

44
SAML 1.1 Extensions

• Extensions to SAML 1.1 specification
• Shibboleth
• Authn Request Profile
• SP-first browser profiles
• Attribute Request Profile
• Liberty ID-FF
• Yet another XML layer on top of SAML
• Numerous new and useful profiles
• SAML 2.0
• Convergence of SAML 1.1, Shib and Liberty

45
Shibboleth Implementations

• Shibboleth is both a specification (extension of
  SAML 1.1) and an implementation
• Implementations of Shibboleth (the spec)
• Shibboleth (of course!)http//shibboleth.internet
  2.edu/
• Guanxihttp//www.jisc.ac.uk/index.cfm?nameprojec
  t_guanxi
• AthensIM (IdP only)http//www.athensams.net/shibb
  oleth/AthensIM/
• There are more open source implementations of
  Shibboleth than there are of SAML itself!

46
Liberty Implementations

• Implementations of Liberty ID-FF
• SourceID ID-FF 1.2 Java Toolkit
  2.0http//www.sourceid.org/projects/id-ff-1.2-jav
  a-toolkit.html
• Lassohttp//lasso.entrouvert.org/
• 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

47
SAML1 Resources

• SAML V1.1 Technical Overviewhttp//www.oasis-open
  .org/committees/download.php/6837/sstc-saml-tech-o
  verview-1.1-cd.pdf
• Shibboleth Technical Overviewhttp//shibboleth.in
  ternet2.edu/docs/draft-scavo-shib-techoverview-01.
  pdf
• Wikipediahttp//en.wikipedia.org/wiki/SAML
• SAML1http//trscavo.blogspot.com/2004/10/saml1.ht
  ml

48
SAML 2.0
49
SAML 2.0

• SAML 2.0 became an OASIS standard in Mar 2005
• Some 30 individuals were involved with the
  creation of this specification
• Project Liberty donated its ID-FF spec to OASIS,
  which became the basis of SAML 2.0

50
SAML2 Features

• Significant new features in SAML2
• Convergent technology (SAML1, Liberty, Shib)
• Streamlined XML syntax
• New protocol bindings
• SP-first browser profiles
• Session management (i.e., Single Logout)
• Name identifier management
• Metadata specification
• Authentication context
• Fully extensible schema

51
SAML2 Use Cases

• SAML2 has broader scope than SAML1
• While typical use cases are still focused on the
  browser user, other use cases are discussed in
  the spec
• Two notable use cases outside the TC
• SAML 2.0 Profile of XACMLhttp//docs.oasis-open.o
  rg/xacml/access_control-xacml-2.0-saml_profile-spe
  c-cd-02.pdf
• Liberty ID-WSF 2.0http//www.projectliberty.org/r
  esources/specifications.php

52
SAML2 Bindings

• Supported SAML2 protocol bindings are outlined in
  a separate document
• SAML SOAP Binding (SOAP 1.1)
• Reverse SOAP (PAOS) Binding
• HTTP Redirect (GET) Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML URI Binding

53
SAML2 Profiles

• SAML2 profiles include
• SSO Profiles
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile
• Attribute Profiles
• The profiles spec is simplified since the binding
  aspects have been factored out

54
SAML2 SSO Profiles

• SAML2 SSO profiles include the following
• Web Browser SSO Profile
• Enhanced Client or Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Identifier Management Profile
• All of this is new except the refactored Web
  Browser SSO Profile

55
Web Browser SSO Profile

• Unlike SAML1, the SAML2 browser profiles are
  SP-first and therefore more complex (see the
  Shibboleth browser profiles for the simplest
  examples)
• SAML2 adds a element to the
  protocol, which takes the notion of
  authentication request to its logical conclusion

56
Browser Profile Examples

• In SAML2, the Browser SSO Profile is specified in
  very general terms
• An implementation is free to choose any
  combination of bindings, which leads to some
  interesting variations
• Well give just two examples here
• SAML2 version of SAML1 Browser/POST
• SAML2 Browser/Artifact with a double artifact
  binding

57
Browser/POST Profile

• A SAML 2.0 Browser/POST Profile (others are
  possible) consists of eight steps
• Request the target resource SP
• Redirect to the Single Sign-on (SSO) Service
• Request the SSO Service IdP
• Respond with an HTML form
• Request the Assertion Consumer Service SP
• Redirect to the target resource
• Request the target resource again SP
• Respond with the requested resource

58
Browser/Artifact Profile

• A SAML2 Browser/Artifact Profile with 12 steps
• Request the target resource SP
• Redirect to the Single Sign-on (SSO) Service
• Request the SSO Service IdP
• Request the Artifact Resolution Service SP
• Respond with a SAML AuthnRequest
• Redirect to the Assertion Consumer Service
• Request the Assertion Consumer Service SP
• Request the Artifact Resolution Service IdP
• Respond with a SAML Assertion
• Redirect to the target resource
• Request the target resource again SP
• Respond with the requested resource

59
IdP Discovery Profile

• SAML2 Identity Provider Discovery Profile (IdPDP)
  specifies the following
• Common Domain
• Common Domain Cookie
• Common Domain Cookie Writing Service
• Common Domain Cookie Reading Service
• Hypothetical example of a Common Domain
• NWA (nwa.com) and KLM (klm.com) belong to SkyTeam
  Global Alliance (skyteam.com)
• NWA common domain instance nwa.skyteam.com
• KLM common domain instance klm.skyteam.com

60
IdP Discovery Profile (contd)

• Common Domain Cookie
• Stores a history list of recently visited IdPs
• Common Domain Cookie Writing Service
• The IdP requests this service after a successful
  authn event
• Common Domain Cookie Reading Service
• The SP requests this service to discover the
  user's most recently used IdP

61
Single Logout Profile

• Like Liberty, SAML2 specifies a Single Logout
  (SLO) Profile
• SLO requires session management capability
• SLO is complicated, requiring significant new
  functionality in a conforming implementation

62
Assertion Query/Request Profile

• The Assertion Query/Request Profile is a general
  profile that accommodates numerous query types
• The SAML SOAP binding is often used

63
SAML2 Attribute Query

• For example, here is a SAML2 attribute query
  stubVersion"..." IssueInstant"..."
  Destination"..." Consent"..."
  ...
  ... ...ubject ...amlpAttributeQuery
• There may be multiple elements

64
SAML2 Attribute Profiles

• The elements adhere to a SAML2
  Attribute Profile
• Basic Attribute Profile
• X.500/LDAP Attribute Profile
• UUID Attribute Profile
• DCE PAC Attribute Profile
• XACML Attribute Profile

65
X.500/LDAP Attribute Profile

• A sample LDAP attributexmlnsx500"urnoasisnamestcSAML2.0profilesa
  ttributeX500" NameFormat"urnoasisnamestcSA
  ML2.0attrname-formaturi" Name"urnoid2.5.4.
  42" FriendlyName"givenName"
  x500Encoding"LDAP" Steven
  
• Since eduPerson is bound to LDAP, the new SAML2
  attribute profile will facilitate sorely need
  interoperability

66
Metadata Specification

• Metadata standards are important for
  interoperability
• SAML2 specifies a significant metadata framework,
  which is completely new
• Some of the metadata elements have already
  filtered down into SAML1 and Shibboleth

67
Authentication Context

• The AuthenticationMethod attribute in SAML 1.1 is
  replaced by an authentication context in SAML 2.0
• The authn context formalism is very general, but
  numerous predefined classes (25 in fact) have
  been included to make it easier to use