Steps To Integrate SSO With Drupal Using SAML

Raise your hands if you’re excited about visiting every website once? Someone? didn’t believe that.

Customers follow firms that put convenience first. One such practical feature that relieves your consumers’ burden and leaves them feeling delighted is Single Sign-On (SSO). It saves a ton of time, improves security (by lowering password breach attacks), and boosts output. Actually, companies who have implemented SSO have also noticed a rise in the rate of user acceptance. Would you like more information about how to incorporate SSO into your Drupal website? Go into the details and continue reading!

What is SSO ? 

A user authentication solution called Single Sign-On (SSO) enables users to utilize a single login password across all linked platforms. Alternatively, you can log in by just clicking a button if the main program already has an open session.

As an illustration:

We can use Quora as an example, since the forum lets you utilize social network logins (Facebook and Google) in addition to creating a new account and logging in with those credentials.

Types of SSO Protocols

To do this, there are numerous possible protocols, just like with any other notion. Among the standard procedures are:

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

Things to know before we start

XML Key Generation and Certificate

XML

An HTML-like markup language is called XML (eXtensible Markup Language). Data can be transported and stored by it.

Example:

<start>

 <first>Data1</first>

 <new>NewData</new>

</start>

Certificate/Key Generation

In SAML-based SSO, certificates and private keys are essential components. They validate incoming requests since they are utilized for security purposes.

Use the following terminal command to create an OpenSSL certificate and private key:

openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crt

How it Works

The application requesting login is referred to as a Service Provider (SP) in SAML SSO, and the application supplying the authentication data is known as the Identity Provider (IdP).

Flow:

The browser makes a request to the SP server when a user tries to log in.

For authentication, SP will create a SAML request and forward it to the configured IdP URL (in SP). The SAML request comprises SAML data in XML format.

The SAML data from the request XML will then be validated by the IdP using the SP’s pre-configured data (in IdP).

After being validated, IdP will use the current email address (by default, although this can be changed) and other data for validation to create an XML formatted SAML response to the ACS URL from the SP’s SAML request.

SP will now authenticate the user of the email address in the SAML response and validate the data in the answer.

In this case, the redirected application (SP/IdP) will decrypt the encrypted SAML response and request.

Drupal can be improved for use as an identity provider, however it is typically used as a service provider.

Three distinct SAML Request (AuthNRequest) kinds are possible:

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>

Several SAML Response kinds are possible:

SAML Reaction

<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>

Available Modules for SSO

We have a list of Service Provider and Identity Provider modules in Drupal. Several SP and IdP modules are as follows:

Modules for SP:

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

Modules for IdP:

• IDP for Light SAML
• MiniOrange SAML IDP (Paid Version) SAML IdP

Examining Instruments:

• With the following tools, we can debug the SAML request even though the data is encrypted.
• SAML Tracer for Firefox on Mozilla.
• Google Chrome’s SAML Chrome Panel.

How to use SAML to integrate SSO with Drupal

Set up the SSO module in SP.

Here, we’ve configured Drupal as a service provider by utilizing the saml_sp module.

Set up the SP module’s settings.

• Make the private key and certificate, then store them somewhere that Drupal can read them.
• Put the module in place.
• require ‘drupal/saml_sp:^4.2’ in composer
• Under the Extend section, enable the module.

Navigate to the module’s configuration at /admin/config/people/saml_sp.

Set up the SP parameters.

If you would like to override the default https://sp.lndo.site/user, provide the entityID. This domain is https://sp.lndo.site.

• Give a comparable assertion URL to https://sp.lndo.site/saml/consume.
• Give any further information that is required.

When using Sign, be sure to use the appropriate algorithm and the appropriate assertion and encryption type according on the requirements (based on the requirement of IdP).

Give the file path for the private key and certificate.

Metadata will be produced based on the supplied data. The SP data in IdP will be configured using this XML metadata.

• Set Up SP’s Identity Providers
• Click Add Service Provider under Identity Providers.

2. Include the information from the IdP-provided metadata file or URL.

Once the aforementioned are set up, we can use the Drupal Login module in SAML SP. Configure the SAML login process under the Login Menu. As an illustration, suppose a user having an IdP account but no SP account creates an SP account with an authenticated role.

Configure SSO module in IdP

The light_saml_idp module has been utilized in this instance to prepare Drupal for usage as an identity provider.

Establish the IdP module’s settings:

1. Create the private key and certificate, then store them somewhere that Drupal can read them.
2. Put the module in place.
3. In the Extend section, turn on the module.

Navigate to the “people” configuration at /admin/config/light_saml_idp.

• Enter the entity_id here.
• Give the remaining information that is required.
• Ensure that the private_key and certificate file paths are entered correctly.
• Under the Metadata tab, metadata will be generated as soon as the data is submitted. To configure there, SP needs to receive this.
• With the information from the SP metadata, add the service provider under the service provider.

Once these have been successfully configured, the SSO will function as intended. Joy! SSO integration goes well.

Use testing tools to confirm the cause of the problem if you are unable to use the SSO.

Conclusion