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. This can then be very specific where authentication takes place.

Auth Response

Example SAML Auth Response

Here is an example Auth Response

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
    <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
    <saml:Subject>
      <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
      <saml:AudienceRestriction>
        <saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

InResponseTo

This is always included in the SAML Message and is used to verify a valid response for the request.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
...
InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">

...
</samlp:Response>

Status

This provides the status of the processing and an optional StatusMessage or StatusDetail. To be a successful response must contain a SAML Assertion (It can contain more).

SAML Assertions

An Assertion will contain attributes

• Subject User details and how to verify the subject
• Conditions Authentication Details
• AttributeStatement User details
• AuthStatement Authentication Details

Subject

This provides a method to confirm the subject. The main approach is something called the bearer method which states possession of the assertion and subject is enough to verify the user. (I am assuming this message)

Conditions

This include expiry times for the assertions. This may also contain the AudienceRestriction and as an SP you should validate the value is you.

AttributeStatement

This describes the authentication event. It contains the Authentication Context which show how the use authenticated.

AuthStatement

Like OAuth claims and contains identity data like first name, last name.

NameID Format

Introduction

This should be opaque i.e. not recognizable like name and should not be changeable (immutable).

Pairwise

This allows for a Unique ID per service Provider.

SAML Signing

Signing is done using public/private key. It is recommended that you do sign requests but a lot of implementations do not. For responses it is recommended you sign the assertion and the outer most element which contains the assertion.

SAML Redirect Binding

This is where the SP issues a 302 (Redirect) to the IdP in the query string.
To make the protocol message fit the message is

• Compressed using the Deflate Algorithm
• Base64 Encoded
• Url Encoded
• Assigned to the SAMLRequest or SAMLResponse query Parameter
• Relay State is encoded and added in the RelayState query parameter
• Signature Algorithm is encoded add added in the SigAlg query parameter

SAML POST Binding

This posts the response to the recipient directly and removes the query string length restrictions add better security with https in the body. To Post data and redirect the user to recipient SAML uses Form post with a self submitting form.

SAML Artifact Binding

Instead of sending a response the IdP sends an artifact
Here is the structure of an Artifact

• Type Code is always the same value
• Endpoint Index references the artifact resolution service endpoint where the artifact should be swapped.
• Source ID is entity of the provider who created the artifact
• Cryptographic handle to the message which created the artifact

Then the artifact is sent to IdP Resolution Endpoint in a soap message.
This in turn replies with a response similar to previous reponse.
With Artifacts it means

• Removes all user data from browser
• You can use signing
• Mitigates attack vectors

Single Logout (SLO)

This allows signing out of many Service Providers.
However these signouts may be done in order and can sometimes mean a poor user experience. Some definitions

• SP-Initiated SLO Service Provider initiates the SLO
• IdP -Initiated SLO Identity Provider initiates the SLO

Securing a Implementation

Recommendations

Some definitions

• Asymmetric Encryption Public Encrypt/Private key decrypt
• Deterministic The signature is the same each time e.g. RSASSA-PKCS1-v1_5
• Probabilistic The signature is different each time e.g. RSASSA-PSS
• Elliptical Curve Cryptography much safer, also uses probabilistic The signatures e.g. ECDSA

Bad implementations of ECDSA have been seen. See https://medium.com/asecuritysite-when-bob-met-alice/not-playing-randomly-the-sony-ps3-and-bitcoin-crypto-hacks-c1fe92bea9bc
Recommendations

• Dont use IpP-Initiated SSO
  
• Use rsa-sha256 (Only downgrade where you need with)
• Use XML Encryption for the Assertion to avoid private data. Recommended was AES-256-GCM and RSA-OAEP

API Access

OAuth vs SAML

OAuth does not have context to a user whereas SAML does provide this. Giving you the ability to start a session.

OAuth Authorization Flow

In normal OAuth, we send an authorization request and receive and authorization code. We use the code to request an access token.

Solution 1 Where SAML IdP and OAuth Server are the Same

Where SAML is implemented on the same server as OAuth we could authenticate with SAML and then proceed as we do with OAuth. e.g.

Solution 2 Where we use OAuth without an Authorization

We could authenticate with SAML and just get an access token. But this has several problems.

• API does not know who the user is
• Easy to impersonate
• API authorization rules live in the client

Solution 3 SAML profile for OAuth

This is where we exchange the SAML assertion for an OAuth access token. We do this by sending the SAML assertion to the OAuth server using the grant type oauth:grant-type:saml2-bearer. Validation in server will check

• Assertion is in Date
• The correct application is using the assertion
• The assertion was issued by itself or known trusted provider
• That is has a valid signature