Security Assertion Markup Language (SAML 2.0)

  • XML-based framework that enables exchange of identities/access (authentication and authorization) information in a safe, secure and standard way
  • It is used to provide Single Sign-on (SSO) and Single Logout (SLO) between security domains
  • enables web-based, cross-domain single sign-on (SSO)
  • uses security tokens that contain assertions, which are used to  pass data between a SAML Identity Provider (IdP) and a Service Provider (SP)
  • Documents – SAMLCore, SAMLBind, SAMLProf, and SAMLMeta
  • SAML specification was developed and is maintained by the Security Services Technical Committee of OASIS.
  • SAML 2.0 became an OASIS Standard in March 2005

Why SAML?

  • Interoperable – SAML provides a set of interoperable standard interfaces. Standardizing the interfaces between systems allows for faster, cheaper, and more reliable integration
  • Platform neutrality. SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.
  • Loose coupling of directories. SAML does not require user information to be maintained and synchronized between directories.
  • Improved online experience for end users. SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows for a better-customized user experience at each service while promoting privacy.
  • Reduced administrative costs for service providers. Using SAML to ‘reuse’ a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information.This burden is transferred to the identity provider.
  • Risk transference. SAML can act to push responsibility for proper management of identities to the identity provider, which is more often compatible with its business model than that of a service provider.

Roles

Principal

  • Requests a service from Service Provider

Identity Provider (IdP)

  • Asserting party – Authenticates the identity

Service Provider (SP)

  • requests and obtains an authentication assertion from the identity provider

SAML Components

Source

SAML Core

SAML Bindings

SAML SOAP binding

SAML MetaData

SAML Profiles

  • Specification [SAMLProf] provides a baseline set of profiles for the use of SAML assertions and protocols to accomplish specific use cases or achieve interoperability when using SAML features
  • Combinations of assertions, protocols and bindings to support a defined use case
  • concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings
  • https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf

SSO Profiles

Web Browser SSO Profile

Enhanced Client or Proxy (ECP) Profile

Identity Provider Discovery Profile

Single Logout Profile

Name Identifier Management Profile

Artifact Resolution Profile

Assertion Query/Request Profile

Name Identifier Mapping Profile

SAML Attribute Profiles

SAML Assertion

  • package of information that supplies zero or more statements made by SAML Authority (asserting party) and received by relying party
  • <Subject> – Not necessarily but usually a human about which something is being asserted. subject and principal are used interchangeably sometimes
  • 3 types of assertion statements
    1. Authentication – assertion subject was authenticated by particular means at particular time
    2. Attribute – assertion subject is associated with supplied attributes
    3. Authorization Decision – allow assertion subject to access specific resource (grant or deny)

SAML Protocols

  • What is transmitted?
  • Requests and responses for obtaining assertions and doing identity management

Authentication Context

  • Detailed data on types and strengths of authentication

SAMLV2 Design Standards

XML

  • SAML exchanges encoded in XML
  • Use XML namespaces [XMLNS]
    Prefix XML Namespace
    saml: urn:oasis:names:tc:SAML:2.0:assertion (Assertion Namespace)
    samlp: urn:oasis:names:tc:SAML:2.0:protocol (Protocol Namespace)
    ds: http://www.w3.org/2000/09/xmldsig#
    xenc: http://www.w3.org/2001/04/xmlenc#
    xs: http://www.w3.org/2001/XMLSchema
    xsi: http://www.w3.org/2001/XMLSchemainstance
  • Assertions and protocols specified in XML Schema (XSD)
  • XML Signature used for digital signatures for message integrity
  • XML Encryption provides elements for encrypted

Common XML Elements in SAML

 <Assertion>

 Basic information common to all assertions. It further includes elements and attributes. Some of them are:

Version Required. SAML version e.g. “2.0”
ID Required. unique identifier for the assertion
IssueInstant Required. The time instant of issue in UTC
<Issuer> Required. SAML authority making claim in the assertion
<ds:Signature> Optional. XML signature. If it is present, relying party MUST verify that signature is valid
<Subject> Optional. Required in case of assertion with no statements
<Conditions>

XSD

<element name="Assertion" type="saml:AssertionType"/>
<complexType name="AssertionType">
   <sequence>
     <element ref="saml:Issuer"/>
     <element ref="ds:Signature" minOccurs="0"/>
     <element ref="saml:Subject" minOccurs="0"/>
     <element ref="saml:Conditions" minOccurs="0"/>
     <element ref="saml:Advice" minOccurs="0"/>
     <choice minOccurs="0" maxOccurs="unbounded">
       <element ref="saml:Statement"/>
       <element ref="saml:AuthnStatement"/>
       <element ref="saml:AuthzDecisionStatement"/>
       <element ref="saml:AttributeStatement"/>
     </choice>
 </sequence>
 <attribute name="Version" type="string" use="required"/>
 <attribute name="ID" type="ID" use="required"/>
 <attribute name="IssueInstant" type="dateTime" use="required"/>
</complexType>

HTTP

  • SAML uses HTTP as communication/transport protocol
  • SAML assertions are typically embedded in other structures for transport such as HTTP POST requests or XML encoded SOAP messages

Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

SAML Security

  • TLS 1.0+ for transport level
  • XML Signature and XML Encryption for message-level security

Terminology

  • Assertion Queries
    • To load back assertion from cache
  • Attribute Queries
    • Lazy load user claims. Say user is part of 100s of groups. Not a good idea to pass all the attributes in single assertion. This feature can be used to load other information by making back channel call
    • something like /userinfo endpoint in OIDC
  • Artifact Resolution
    • Get assertion without browser agent
    • Get artifact from IdP
    • Exchange attributes with artifact with IdP
  • RelayState
    • maintains state

Resources