Arlina Espinoza Senior Technical Lead
February 20, 2024

Single sign-on (SSO) solutions are exactly what they sound like: authentication tools that enable users to simultaneously sign into multiple applications or databases with a single set of credentials. They are a useful feature across the board, but for developer portals and enterprise sites, where seamless integration with corporate account management and directory systems is required, they’re essential.

SSO offers a streamlined and secure approach to user authentication and access management, benefiting both users and organizations. Some benefits include:

  1. User Convenience: SSO allows users to access multiple applications or services with just one set of login credentials, reducing the need to remember and manage multiple usernames and passwords.

  2. Security: SSO can enhance security by reducing the number of times users need to enter their credentials, thereby reducing the risk of password theft or misuse. Additionally, centralized authentication and authorization mechanisms allow for more effective enforcement of security policies and access controls.

  3. Centralized User Management: With SSO, user accounts and access privileges can be managed centrally, providing administrators with better control over user authentication and access permissions. This centralized approach simplifies user provisioning, de-provisioning, and management tasks.

  4. Compliance: SSO solutions can help organizations comply with regulatory requirements and internal security policies by providing better control and visibility into user access to applications and resources.


Logging into computer with phone


There are many different types of SSO integration, including Google or Facebook-based logins and the like. Developer portals and enterprise sites usually integrate with their account management service, be that Microsoft Active Directory, Okta, Auth0, Ping Identity, or some other service.

While technically SSO deals with authentication (verifying that the user is who they say they are), in practice it goes hand in hand with authorization by informing the system of the level of access the user should have – or, to use Drupal lingo, their roles and permissions.

Most implementations use either SAML or OpenID as their protocol. The most common workflow has the login button in the portal redirect to a third-party identity provider (IdP) service that takes care of authentication, and then seamlessly returns the user to the original portal where they are now logged in.

In terms of Drupal integration, we’ve found both protocols to be robust and supported by a wide range of contrib modules. That said, projects of this kind are not without their challenges, which include the following:

  • Role mapping is not always straightforward. Aside from roles, there is frequently a need to segment users in a more granular fashion based on other properties, such as groups or entitlements, so as to allow implementation of complex access control rules for content.
  • Different environments (like dev and prod) may have different IdP configurations. This issue can usually be solved with configuration overrides or config split.

  • Roles and grouping should ideally be managed in the IdP, which means the user’s information should be fetched and evaluated upon every login.

  • It is not uncommon to integrate with multiple IdPs. Again, roles and groups assigned might be different depending on which IdP they are coming from.

  • Some site builds use the popular but somewhat antiquated SimpleSAMLphp. While highly versatile, it is challenging to configure and debug. I personally favor SAML Authentication, which is based on SAML PHP Toolkit, for its configuration simplicity (all within Drupal), robustness, and extensibility.

  • Developer portals frequently need to run user requests through the company APIs. In this case, an OAuth-based SSO solution is preferred, which allows the portal to use refresh tokens on behalf of the user to interact with the resources. Under this scenario, careful planning is needed, as the SSO implementation needs to integrate with other OAuth client modules.

The way we approach these difficulties is through careful examination to uncover the ways in which user identity and access control will be used across the site. Then, we develop an implementation plan, mapping the operational requirements to Drupal architecture. Out-of-the-box solutions provided by the Drupal modules may not cover the uniqueness of each client’s needs, and custom modules are often required to integrate the functionality and implement business logic that fully describes the requirements.

We’ve encountered our share of interesting SSO and access control scenarios over the years, and we can happily report that our solutions have not only addressed the complexities of these use cases but have also endured the challenges of time.

Are you looking to launch into the developer portal space? Chapter Three has extensive experience in creating these platforms. You can read more about our experiences with developer portals here and here. For this and any other web projects, please contact us and get us working for you.