Single Sign On with SAML2.0
The SAML2.0 Protocol.
SAML or Security Assertion Markup Language is a protocol created in 2002 by OASIS (Organization for the Advancement of Structured Information Standard). The protocol allows a secure exchange of information related to identification data. Its version SAML 2.0 was created in 2005 and is still widely used for Single sign-On (SSO) in large companies and government institutions.
The SAML protocol is mainly used to manage a user’s permissions with service providers. SAML is a single sign-on (SSO) protocol. This allows users to access different services and applications. Using a single login, for the duration of a session.
To fully understand the value of SAML, it is important to understand what SSO is.
What is the SSO?
To understand SSO, let’s use an example. We have a HelloWorld company that is growing. This company has more and more internal services and applications, such as an HR system, an admin portal, internal documentation or an employee benefits application. HelloWorld wants its employees to use these different services.
To be able to use all the company’s services. Each employee will have to create an account and log in to each service individually.
The experience for the employee is not optimal. Every time they change applications, they have to log in. Each time the employee logs out, he should enter his login credentials for each tool. The login experience depends on the security system of each external tool. It has no control over it, except for these internal applications.
To improve the experience and security of these employees, HelloWorld can implement single sign-on (SSO). With SSO, the authentication process is outsourced to a single, dedicated security service. The employee will be able to log in to all these tools with a single unique identifier.
SAML2.0 is not the only protocol for SSO. There’s also the OpenID Connect protocol. If you want to know more about this protocol, I invite you to read the article: Adding an Identity layer to OAuth2 with the OIDC protocol.
How SAML2.0 works?
SAML2.0 uses XML to represent user identity data and HTTP for the data transport mechanisms (binding type). The protocol is based on 3 main roles.
SAML 2.0 roles.
User: in our case, the employee.
Service Provider or SP: the web service or application that our User wishes to access.
Identity Provider or IdP: the system in charge of user authentication, which decides whether the user can access an SP.
In this article, we will use the following acronyms: SP for Service Provider and IdP for Identity Provider
The FLOW
Let’s take the example of the company HelloWorld and our employee Emma. She wants to log in to her meal vouchers portal. The SP will query the IdP to see if she can access the service.
Step 1: user wants to use the service.
Let’s start at the beginning. Emma goes to her browser. Then accesses the Swile web application to check her meal vouchers and logs in with her company’s SSO
Step 2: SP request for authorisation
We will focus on step 2 of the illustration: SP request for authorization. That means the beginning of the SAML flow starts with the SAML request: AuthnRequest.
The AuthnRequest is the request sent by the SP and received by IdP. In this request, we find the information that identifies the SP and also the information that the IdP needs to authenticate a user.
In the XML, the 3 attributes that are mandatory for any SAML message for authentication requests or responses are :
ID="_e45fckd989jksdjf989dsfk0e9dcc24"
Version="2.0"
IssueInstant="2022-08-01 T10:52:45Z"- ID: unique identifier for the message
- Version: version of the SAML protocol
- IssueInstant: creation date of the message.
The IssueInstant can use to detect fraudulent calls. If the IdP has already received an authentication request less than 30 minutes ago. It is a red flag that tells that it cannot trust the request it has received and not parse the XML.
Other attributes are available in the XML:
- Destination: SSO SAML endpoint of the IdP. If the declared value is not the expected one, it is a signal for the IdP not to trust the request. Being an optional attribute, it is not necessarily available. If you have the choice, add it as it can be a good indicator of fraud and you can disable it for IdPs that do not support it.
Destination="http://idp.example.com/saml/sso"- AssertionConsumerServiceURL: endpoint where the SP wants the response to be sent. This endpoint must be known to the IdP in advance which allows SAML responses and assertions to be managed.
- ProtocolBinding: how the SP wants the response to be sent.
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://sp.example.com/saml/acsThere are 4 types of binding that allow the SP and IdP to communicate with each other:
- HTTP redirect: default option that is often used to redirect within the browser for SSO.
- HTTP Post: use of an HTML form whose content is base64 encoded.
- HTTP artifact: binding is used when the content of the message should not be exposed.
- SOAP: binding that uses the SOAP (Simple Object Access Protocol)
If we return to our AssertionConsumerServiceURL and ProtocolBinding attributes. It is important to know that they do not necessarily have to be sent together. Only one of the two can be present. We can have an alternative to these two attributes which is the AssertionConsumerServiceIndex. If none of these 3 attributes is present in the XML. The IdP will then use the ACS URL and the binding type that is configured by default for the SP.
- Issuer: contains the unique identifier of the SP that created the request. Without this information, the IdP will not understand who made the request and how to validate it.
<saml:Issuer>http://sp.example.com/saml/metadata</saml:Issuer>There are attributes that can be used to modify the default behaviour of an IdP.
- ForceAuthn: SP will ask to force the authentication of a user even if his session is still active. This can be used if you want an admin who connects to his back office to be authenticated less than 4 hours ago. Or to verify that the user using the session is the correct user and not an abandoned session.
- RequestedAuthnContext: makes sure that the user is connected in a certain way (e.g. double factor user).
- Scoping: SP can specify a list of IdPs with which it allows communication. For example, if you want to authenticate the user only via a social authentication like Google. Defining a unique IdP will automatically forward the request to Google IdP.
<Scoping>
<IDPList>
<IDPEntry ProviderID="google" />
</IDPList>
</Scoping>Step 3: authentication user
The IdP must identify the user and then proceed to step 4 of the illustration to return a SAML response.
Step 4: authorisation to access the service
The SAML response is composed of an XHTML form and an assertion.
We will find the attributes we saw above for the request (ID / IssueInstant/ Destination / Version). For the Destination, the URL changes, and it points to the SP.
- InResponseTo: the identifier of the original authentication request. This identifier allows the SP to verify the integrity of the value sent by the IdP, thus avoiding the injection of stolen responses.
InResponseTo="_4fee3b046395c4e751011e97f8900b5273d56685">- Issuer: the unique identifier of the IdP that generated the SAML response.
<saml:Issuer>http://idp.example.com/saml/metadata</saml:Issuer>- Status: the status is optional. It is used to display the status of the response to the user.
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>A valid answer must have at least one assertion.
An assertion contains :
- Subject: we have the id of the subject
saml:NameIDand how to confirm the subject to verify the assertionsaml:SubjectConfirmation. The id inInResponseTomust be the same as the request id. TheRecipientmust match the ACS endpoint on the SP.
- Conditions: conditions must be checked before trusting what is in the assertion.
In the Conditions saml:AudienceRestriction> is a set of hearings defined by which the assertion must be read and validated. If the SP receives an assertion that is not intended for it, it must reject it.
- AttributeStatement: describes the authentication events. The value tells us when the user lasts authenticated. This attribute can also help us if we want to force authentication, as in the case of an administrator.
You can also use SessionNotOnOrAfter="2022-08-17T09:01:48Z" to inform of the end of the user’s session in the IdP. The SP can end the session at the same time as the IdP but there is no obligation to it. The attribute saml:AuthnContext describes how the user is authenticated, using the same values found in the request.
- AttributStatement: contains many of the user’s identity attributes.
Step5: access to the service
Once the first authentication flow has been completed, where the user identifies himself to the IdP. He started a single sign-on session, which resulted in also starting an authentication with the SP, our employee wanted to use. As long as the user’s session is active, he will not need to authenticate again to any other service authorised by his company’s IdP.
If Emma wants to see the amount of her meal vouchers and will use the external application of her company. The application will interact with the IdP to find out if the person can access the service. The IdP, on its side, can see that a session is still active and the user has the right to access this service. The IdP will then inform the SP by sending an XML response. The SP will then give Emma access to the service.
How to sign the SAML request and response.
For more security, it is preferable to sign the different messages sent between (the request and the response) the SP and the IdP.
Signing authentication requests ensures that only the SP can request SAML assertions. The signing also puts user data out of reach of a potential attacker.
Security within the SP can be enhanced by implementing a system to combat Cross-Site Request Forgery (CSRF).
CSRF is a type of attack that occurs on a service by forcing a user’s web browser to perform unwanted operations. While the SP has measures in place against CSRF. We are fairly confident that it is very unlikely that attackers can change the request ID to carry out injection attacks.
The response and assertions must also be signed. Otherwise, an attacker can change the name ID and various attributes to impersonate a user.
To sign the SAML request and response, we can use XML digital signatures and a public key. The signer of the message will encrypt the message. Use it to create a signature generated with a private key that only he knows. He will then add this signature to the XML file.
To verify the message sent, the recipient will use the same hash algorithm as the sender. Use the public key to verify the signature. If the signature is validated, the data was generated by the known trusted party and has not been modified by a malicious third party.
- SignedInfo: information on how the signature was created.
- CanonicalizationMethod and Transforms: indicate how the XML is encoded in order to generate exactly the same value to be passed to the sender’s hash algorithm.
- SignatureMedhod: indicates how the XML is encoded in order to generate exactly the same value to be passed to the sender’s hash algorithm.
<SignatureMethod Algorithm="http://www.w3.org/2001/04/
xmldsig-more#rsa-sha256"/>The signature may also contain information about the public key that the recipient must use to validate the signature.
<KeyInfo>
<KeyName>
878979878-89878djfv-98skjdfkljdsljf
</KeyName>
</KeyInfo>It is possible to have a key presence in the signature. If you find yourself in this case, you should never use it in production, but as a hint or for debugging. Under no circumstances, should you use it to verify a signature, as it could have been placed by an attacker. You should only trust keys that you know in advance.
In summary, SAML2.0 is still quite restrictive to set up and has security flaws that are related to the use and processing of XML.
SAML was designed to be used on the server side. Implementing SAML SSO on the SPA or native application side is possible but very complex and less secure.
