Security Assertion Markup Language (SAML)

The OASIS Security Services Technical Committee (SSTC), in 2001, had the very ambitious goal of defining an XML framework that could be used for exchanging authentication and authorization information. WS-Federation only partially achieved this as SAML also adopted the XML format for the request and response messages, unofficially signing the death warrant for the declining SOAP specification.

The SAML protocol came out of the joint efforts of several companies that were part of this committee as a passive and claim-based authentication protocol for federated identities.

The SAML specification defines three roles:

• The principal (typically, this is a user, also known as the subject)
• The IdP
• The service provider

In a typical SAML use case, the principal requests a service from the service provider. The service provider usually redirects a user accessing it from a web browser to the IdP to obtain an authentication assertion (a signed security token). Based on the assertions included in the token, the service provider can decide whether to authorize the security principal that completed the authentication flow or simply block the access because the requested permissions cannot be requested.

Before issuing the signed security token to the service provider, the IdP may require the user to prove their identity, usually by asking for a username and a password.

Here is an example of an extract from a signed SAML response token:

<?xml version="1.0" encoding="utf-16"?>
[..]
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sts.katsuton.com/adfs/services/trust</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
[..]
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[..]
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
[..]
    <ds:SignatureValue>OUPJpFsnUODCK2h7T5SYMVhlWDnCBT6Qy T9CcVnrjcWUPZTAaz2FNGEpPPhb/P9kW23cw5D1+fjhtAQurN/Du9uYfdkGtXcTPfcOOVfuzgQT1d75HmYnbAtTvhsOrS8gvGCY6o Jk3wsqNar3hrqLHDFxsszY41lZvOe2/Qax1SMpHeglQSbu6WOFe3sPdSiLY8rnWBE5QubS85N1E+HNvjHqXS7Luwr RDNK0InMM+LdPZw1YdOGUikgTbyIFKMR/eXR5UqbVrvmwv58XxT9C5p7FYPu3eKjWLD2aGjCnJufFNfHiVGYrB8OU1FN1E/2sLNXnSuMyNnQJ5iWCQWP3vQ==</ds:SignatureValue>
[..]
        </ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">[e-mail]</NameID>
</Subject>
[..]
        <Conditions NotBefore="2021-06-28T09:26:39.720Z" NotOnOrAfter="2021-06-28T09:27:39.720Z">
            <AudienceRestriction>        
    <Audience>urn:microsoft:adfs:claimsxray</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
      <AttributeValue>kadmin</AttributeValue>
            </Attribute>
            </AttributeStatement>
[..]
</samlp:Response>

Let’s discuss the main pieces of information within the token:

• Issuer: This is the identifier of the IdP that issued the token.
• Status code: The status code of the whole authentication process. If anything other than success is returned, then the receiving party (typically, the service provider) has to raise an error.
• Signature method: The signature algorithm that’s used to sign the token.
• Signature: The signature of the token. The signature can be calculated for the entire response or just for the assertions within the token: it must be agreed upon upfront between the parties involved.
• Validity: The time window when the token is considered valid. Once the token has expired, the user must return to the IdP and ask for another token.
• NameId: The SAML token’s part that uniquely identifies the user. It can contain the user’s username in different formats (for example, userprincipalname format), which are usually specified in the Format attribute.
• Audience: The party the token has been issued for. An application (service provider) must control whether the token it receives has been issued for itself and not for another application by checking the Audience field.
• Attributes (claims): A list of assertions regarding the authenticated user needed by the service provider to authorize access and implement its business logic.

Most of the information provided here can be found in different types of tokens, such as JWTs in the OAuth 2.0 and OIDC protocols. To avoid confusion, please note that SAML is both the name of the token format and the protocol. WS-Federation uses SAML tokens within its authentication flows.

SAML does not specify which method of authentication must be used by the IdP. This is a key point: SAML was created to rely on existing authentication protocols. It naturally integrates with them as its source of authentication. Kerberos, LDAP, and Active Directory can still be used as SAML sources of authentication while leaving the SAML protocol with the task of federating with the identities of external companies.