SAML 2.0

Introduction

What is SSO (Single Sign On)

Some definitions

• Authentication Verifying an identify
• Authorization Verifying user has permission and access
• Federation is when authentication is happen across multi vendor apps

SSO is the ability to authenticate via one authority.

Benefits are

• Authentication under your control (Audit, turn off/on etc)
• One set of credentials
• Login once per session

SAML

SAML stands for Security Assertion Markup Language and defines the syntax and processing semantics of assertions made about a subject by a system entity.
In SAML the thing providing the service is the Service Provider (SP) e.g. HR System and the thing providing the Authentication is the Identity Provider (IdP)

Here is an example for a typical workflow where Citrix is the service provider.
If you already have a session and want to access a second service provider no credentials are prompted for and you are logged in automatically.

History

Here is a timeline for some of the protocols in use today in this space.
SAML 1.0 and 1.1 are dead as they relied on SOAP.

For SAML 2.0 parts of the specification are :
Not really used now

• Authorization functionality
• Name ID Management & mapping profiles

Are used

• Web SSO (Single Sign on)
• SLO (Single Logout)
• Artifact Binding

SAML vs OpenID

• SAML
  • Created before OpenID Connect 2005
  • Uses XML and XMLSig which has created security issues
  • Designed for Server-side Web Apps
  • Poor support for JavaScript SPA or Native App like mobile App with Url length limits
  • Implementation is split between service and the Identify Provider
• OpenID Connect
  • Newer than SAML Created in 2014
  • Uses JSON and JWTs
  • Built on OAuth and supports API access and delegation
  • Designed for all modern authentication types including browserless e.g. TV
  • Implementation is largely in the Identify Provider

SAML Detail

Introduction

More terminalogy. Auth requests are sent to the IdP SSO endpoint and responses are returned to the Service Providers ACS Endpoint

• SSO Endpoint Single Sign on Endpoint
• ACS Endpoint Assertion Consumer Service Endpoint

Relay State

A RelayState is an HTTP parameter that can be included as part of the SAML request and SAML response. In an SP-initiated sign-in flow, the SP can set the RelayState parameter in the SAML request with additional information about the request.
It is the equivalent of a forgery token to deter Open Redirect.

Binding Types

SAML provides several ways to communicate from the Service Provider to the Identity Provider and vice-versa. These are known as binding types.

Auth Request

Example SAML Auth Request

Here is an example Auth Request

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
  <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
  <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Common Attributes to Messages

These three attributes are required for every message type. The ID is the unique message identifier and is provided in the response. The IssueInstant is the UTC time the message was created.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
...
ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24" 
Version="2.0" 
IssueInstant="2014-07-16T23:52:45Z" 
...
</samlp:AuthnRequest>

Destination Attribute

Another value present of all messages is the Destination attribute although this is optional. It is recommended to enforce use of this where possible.

Where To Send Attributes

These two below show where to send the response and which binding type to use and must be known to the IdP

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
...
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
...
</samlp:AuthnRequest>

Issuer

Finally we have the Issuer which must be known to the IdP.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
...
  <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
...
</samlp:AuthnRequest>

Popular Options

ForceAuthn

This can be added to force the credentials to be entered even if previously done so. E.g. change password.

RequestedAuthContext

This is where you can request 2FA for instance. These need to be agreed in the IdP and the SP.

Scoping

This is where the SP provides to the IdP a list of other providers which should used for the authentication. E.g. Google.