Specbee: How to integrate SSO with Drupal using SAML

Show of hands for anyone thrilled about logging in to every website every single time? Anyone? Didn’t think so.
When businesses prioritize convenience, customers will follow. Single Sign-On (SSO) is one such convenient feature that leaves your customers feeling satisfied and less stressed. It is a huge time-saver, is more secure (reduces password breach attacks), and increases productivity. In fact, businesses adopting SSO have seen an increase in user adoption rate too. Do you want to learn about how you can integrate SSO with your Drupal website? Keep reading and dive into the details!

What is SSO ?
Single Sign-On (SSO) is a user authentication service that allows users to use one login credential for all the systems integrated with SSO. Or, if there already is an open session in the main application, just clicking a button will log you in.
An example:
We can consider Quora as an example, as the forum allows you to create a new account, log in with those credentials, and also use social media logins (Google and Facebook).

                         Source: https://www.quora.com/
Types of SSO Protocols
Like any other concept, there are many available protocols to achieve this. Some of the common protocols are:

Lightweight Directory Access Protocol (LDAP)
Kerberos
Security Assertion Markup Language (SAML)
OAuth 2
OpenID Connect

Things to know before we start

XML
Certificate/Key Generation

XML
XML (eXtensible Markup Language) is a markup language similar to HTML. It has the ability to store and transport data.
Example:
<start>
<first>Data1</first>
<new>NewData</new>
</start>Certificate/Key Generation
Certificates and private keys play a major role in SAML-based SSO. Since they are used for security reasons, they validate incoming requests.
To generate an OpenSSL certificate and private key, run the following command in the terminal:
openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crtHow it Works
In SAML SSO, we consider the application requesting login as a Service Provider (SP), and the application providing authentication information is the Identity Provider (IdP).
Flow:

When a user tries to log in to SP, the browser sends a request to the SP server.
SP will generate a SAML request (which contains SAML data in XML format) and redirect to the configured IdP URL (in SP) for authentication.
Then, the IdP will validate the SAML data from the request XML with the pre-configured data of SP(in IdP).
Once validated, IdP will generate an XML formatted SAML response to the ACS URL from the SAML request of SP with the current email address (by default which can be overridden) value with other data for validation.
Now, SP will validate the data of the SAML response and authenticate the user of the email address in the SAML response.

                                                                  Source
Here, both the SAML request and SAML Response will be encrypted and will be decrypted in the redirected application (SP/IdP).
In most cases, Drupal is used as a service provider, but it can also be enhanced as an identity provider.
We can have 3 different types of SAML Request(AuthNRequest):

AuthNRequest

<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>
With Signature (HTTP-Redirect binding)

bM441nuRIzAjKeMM8RhegMFjZ4L4xPBHhAfHYqgnYDQnSxC++Qn5IocWuzuBGz7JQmT9C57nxjxgbFIatiqUCQN17aYrLn/mWE09C5mJMYlcV68ibEkbR/JKUQ+2u/N+mSD4/C/QvFvuB6BcJaXaz0h7NwGhHROUte6MoGJKMPE=
AuthNRequest with embedded signature (HTTP-POST binding)

<samlp:AuthnRequest xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol” xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” ID=”pfx41d8ef22-e612-8c50-9960-1b16f15741b3″ 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>
<ds:Signature xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=”http://www.w3.org/2001/10/xml-exc-c14n#”/>
<ds:SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#rsa-sha1″/>
<ds:Reference URI=”#pfx41d8ef22-e612-8c50-9960-1b16f15741b3″>
<ds:Transforms>
<ds:Transform Algorithm=”http://www.w3.org/2000/09/xmldsig#enveloped-signature”/>
<ds:Transform Algorithm=”http://www.w3.org/2001/10/xml-exc-c14n#”/>
</ds:Transforms>
<ds:DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″/>
<ds:DigestValue>yJN6cXUwQxTmMEsPesBP2NkqYFI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>g5eM9yPnKsmmE/Kh2qS7nfK8HoF6yHrAdNQxh70kh8pRI4KaNbYNOL9sF8F57Yd+jO6iNga8nnbwhbATKGXIZOJJSugXGAMRyZsj/rqngwTJk5KmujbqouR1SLFsbo7Iuwze933EgefBbAE4JRI7V2aD9YgmB3socPqAi2Qf97E=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQQFADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcwMDI5MjdaFw0xNTA3MTcwMDI5MjdaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vU/6R/OBA6BKsZH4L2bIQ2cqBO7/aMfPjUPJPSn59d/f0aRqSC58YYrPuQODydUABiCknOn9yV0fEYm4bNvfjroTEd8bDlqo5oAXAUAI8XHPppJNz7pxbhZW0u35q45PJzGM9nCv9bglDQYJLby1ZUdHsSiDIpMbGgf/ZrxqawIDAQABo1AwTjAdBgNVHQ4EFgQU3s2NEpYx7wH6bq7xJFKa46jBDf4wHwYDVR0jBBgwFoAU3s2NEpYx7wH6bq7xJFKa46jBDf4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQCPsNO2FG+zmk5miXEswAs30E14rBJpe/64FBpM1rPzOleexvMgZlr0/smF3P5TWb7H8Fy5kEiByxMjaQmml/nQx6qgVVzdhaTANpIE1ywEzVJlhdvw4hmRuEKYqTaFMLez0sRL79LUeDxPWw7Mj9FkpRYT+kAGiFomHop1nErV6Q==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<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>Reference: https://www.samltool.com/generic_sso_req.php
We can have different types of SAML Response:

SAML 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>The rest of the types can be referred in https://www.samltool.com/generic_sso_res.php.
The request and response can be sent as both GET and POST methods.
Available Modules for SSO
In Drupal, we have a list of modules for Service Provider and Identity Provider. Here are some of the SP and IdP modules:
SP Modules:

SAML Service Provider
SAML Authentication
Onelogin Integration
miniOrange SAML SP(Paid Version) 

IdP Modules:

Light SAML IDP
SAML IdP
miniOrange SAML IDP (Paid Version)

Testing Tools:
Even though the data is encrypted, we can debug the SAML request with the help of the following tools.

SAML Tracer for Mozilla Firefox.
SAML Chrome Panel for Google Chrome.

How to integrate SSO in Drupal using SAML

Configure SSO module in SP
Here we have used the saml_sp module for gearing up Drupal as a Service Provider.
Configure SP module Settings

Create the certificate and private_key and place them in a Drupal-readable location.
Install the module.composer require ‘drupal/saml_sp:^4.2’

Enable the module in the Extend section. 

Go to the configuration of the module (/admin/config/people/saml_sp).
Configure the SP settings

Provide the entityID if you want to override the default https://sp.lndo.site/user. Here https://sp.lndo.site is the domain.
Provide an assertion URL similar to https://sp.lndo.site/saml/consume.
Provide other mandatory details.
Make sure that if you are using Sign specify the correct algorithm and select the Assertion and Encryption type based on requirement(based on the requirement of IdP).
Provide the certificate and private key file path.Based on the data provided, Metadata will be generated. This XML metadata will be used for configuring the SP data in IdP.

Configure Identity Providers in SP

1. Under Identity Providers click on Add Service Provider.2. Add the data from the metadata file/url provided by IdP.
In SAML SP we can use the Drupal Login module once the above are configured. Under the Login Menu, configure the process of SAML login. For example, if a user without an account in SP but with an account in IdP creates an account in SP with an authenticated role.

Configure SSO module in IdP
Here we have used the light_saml_idp module for gearing up Drupal as an Identity Provider.

Configure IdP module Settings:
1. Create the certificate and private_key and place it in a Drupal readable location.2. Install the module.3. Enable the module in the Extend section.

4. Go to the configuration (/admin/config/people/light_saml_idp)

Provide the entity_id.
Provide the other necessary details.
Make sure to provide the correct file path of the certificate and private_key.
Once the data is provided metadata will be generated under the Metadata tab. This needs to be provided to SP to configure there.
Add the Service Provider under the Service Provider, with the data from SP metadata.

The SSO will work properly once these are configured successfully. Hurray! SSO is integrated successfully.
If you are not able to use the SSO, use testing tools to verify what is causing the issue.
Final Thoughts
You just learned how to seamlessly integrate SSO with Drupal using SAML for a stress-free user experience! Considering the protocols, certificates, and complex SAML login flow we’ve explored, SSO plays a significant role in simplifying user authentication. For a seamless SSO journey and Drupal development expertise, look no further than Specbee – your trusted partner in crafting exceptional digital experiences.