At a university, a single person might need to reach the main website, a faculty portal, the library system, a learning platform, and a dozen other applications — and no one wants to log in separately to each one. Single sign-on (SSO) solves this by letting a user authenticate once, with one set of institutional credentials, and gain access to every connected system. For a Drupal site that sits at the center of a university's digital presence, integrating with the institution's SSO is one of the most important pieces of the build.
This guide explains how Drupal SSO integration works and, more importantly, how to choose the right approach. We'll cover the four technologies universities rely on — SAML, Shibboleth, LDAP, and CAS — when each one fits, how the integration works on the Drupal side, and the identity-governance and security decisions that most step-by-step guides leave out.
What Single Sign-On Actually Means
Single sign-on is an authentication model where a user signs in once to a trusted central authority and is then automatically recognized by every application connected to it. The key principle — and the security benefit — is that the individual applications never handle the user's password. With SSO in place, credentials are verified in one place, under one set of policies, rather than being stored and checked separately by every system.
For a university, this matters on several levels at once. Students and staff get a single identity across dozens of services. The IT team manages authentication centrally, applying consistent password rules and multi-factor authentication everywhere. And when someone leaves the institution, disabling one central account cuts off access to everything, instead of leaving orphaned logins scattered across systems. This combination of convenience and control is why SSO is effectively a requirement for any serious institutional web platform.
The Building Block: Identity Provider and Service Provider
Every SSO setup involves two roles, and understanding them makes everything else clearer.
The Identity Provider (IdP) is the trusted central authority that holds user identities and verifies credentials — the institution's Shibboleth service, its Active Directory, or its CAS server. The Service Provider (SP) is the application the user wants to reach — in this case, the Drupal site. When a user tries to access the Drupal SP, it hands the authentication off to the IdP; the IdP verifies the user and sends back confirmation, along with attributes such as name, email, and role; and Drupal then grants access based on that trusted response. In the standard university setup, Drupal acts as the Service Provider and the institution's existing system is the Identity Provider. Getting this relationship right is the foundation of every SSO integration.
The Four Approaches: SAML, Shibboleth, LDAP, and CAS
Universities typically rely on one of four technologies for SSO. They overlap in purpose but differ in origin, mechanism, and where they fit best.
SAML
SAML (Security Assertion Markup Language) is the open standard that underpins most modern enterprise SSO. It's an XML-based protocol for exchanging authentication and authorization data between an IdP and an SP, and it integrates with virtually every major identity platform — Microsoft Entra ID, Okta, ADFS, Google Workspace, and more. In Drupal, SAML is handled through contributed modules that let the site act as a Service Provider, delegating authentication to any SAML-compliant IdP. It's the most broadly compatible choice and the common ground that most other systems can speak.
Shibboleth
Shibboleth is a specific, widely deployed implementation of SAML that is deeply rooted in the academic world. It's the backbone of federated access in higher education and research — the technology behind national and international academic federations that let a student log in at one institution and access resources at another. Technically, integrating Drupal with Shibboleth is a SAML integration: Drupal acts as a SAML Service Provider and Shibboleth serves as the Identity Provider. If your institution is part of an academic identity federation, Shibboleth is very likely the system you'll connect to.
LDAP
LDAP (Lightweight Directory Access Protocol) is not an SSO protocol in the same sense as SAML — it's a protocol for querying a directory of users, most commonly Microsoft Active Directory. Its role in a university is as the underlying source of identity: it stores who exists, their group memberships, and their attributes. Drupal's LDAP integration lets users log in with their directory credentials and can provision Drupal accounts and assign roles automatically based on directory groups. LDAP is often the layer that sits behind an SSO protocol rather than a replacement for one, and it's especially common where the institution runs on the Microsoft stack.
CAS
CAS (Central Authentication Service) is an open-source SSO protocol with roots at Yale University, and it remains widely used across higher education. It was designed specifically for the web-application SSO problem, and it works comfortably alongside authorization stores like LDAP. In Drupal, CAS integration redirects users to the institution's central CAS server to authenticate, then returns them to the site as a logged-in user, with roles assignable based on the CAS response. For universities that already run a campus-wide CAS deployment, connecting Drupal to it is a natural fit.
Which Protocol Should a University Choose?
In practice, the choice is usually dictated by what the institution already runs — Drupal connects to the existing IdP rather than the other way around. The table below summarizes when each approach fits.
| Approach | What it is | Best fit |
|---|---|---|
| SAML | Open standard for federated authentication; broadest compatibility. | Connecting to Entra ID, Okta, ADFS, or any SAML IdP. |
| Shibboleth | Academic SAML implementation; the standard for research federations. | Institutions in a national or international academic federation. |
| LDAP | Directory protocol; the underlying source of user identity. | Microsoft Active Directory environments; role provisioning. |
| CAS | Web-focused open-source SSO protocol, common on campuses. | Institutions with an existing campus-wide CAS server. |
The practical rule is simple: identify the identity provider your institution already operates, then choose the Drupal integration that speaks to it. A university in an academic federation connects Drupal to Shibboleth; one standardized on Microsoft connects through SAML to Entra ID or through LDAP to Active Directory; one running a campus CAS server connects to CAS. It's rarely a green-field choice — the right answer is usually determined by the identity infrastructure already in place.
How SSO Works on the Drupal Side
On the Drupal side, SSO is handled through contributed modules rather than core, and there's a mature ecosystem for each protocol. Whichever module is used, the integration handles a few essential jobs: it redirects unauthenticated users to the IdP, receives and validates the authentication response, and maps the attributes the IdP returns onto a Drupal account.
A concept worth understanding here is just-in-time (JIT) provisioning. Rather than creating a Drupal account in advance for every possible user, JIT provisioning creates the account automatically the first time a person successfully authenticates through the IdP, populating it with the attributes the IdP supplies — name, email, and role. This is what makes SSO scale to a whole university: no administrator manually creates thousands of accounts, and role assignment can be driven automatically by the group memberships the IdP reports. For institutions evaluating the specific modules, the official Drupal.org project pages for SimpleSAMLphp Authentication, LDAP, and CAS document the current, supported options.
Identity Governance: The Part Most Guides Skip
Most SSO tutorials stop once login works. But for a university handling sensitive student and staff data, the harder and more important questions are about governance: who has access, how access is removed, and where identity actually lives. This is where a well-designed integration separates itself from a merely functional one.
The central principle is that Drupal should not maintain its own separate pool of user accounts alongside the institutional identity provider. When local Drupal accounts exist independently, they drift out of sync: they don't get disabled when someone leaves, and they accumulate weak passwords over time. The recommended practice is to disable local password authentication for everyone except a single break-glass administrator account, route all authentication through the IdP, and inherit the institution's multi-factor authentication, password policy, and account lifecycle from that upstream source. In other words, the institution's identity system — not Drupal — becomes the single source of truth for who can log in.
This approach delivers a concrete security benefit: deprovisioning. When a student graduates or a staff member leaves, disabling their central identity account immediately cuts off their Drupal access along with everything else, with no orphaned local login left behind. For an institution accountable for data protection, that single, centralized off-switch is far safer than trying to track down separate accounts across every system.
University Scenarios: Multisite, Lifecycle, and Alumni
SSO in a university context brings a few scenarios that a single corporate site never encounters:
- Multisite single sign-on: Large universities run many sites — a main site plus separate sites for faculties, departments, and research centers. SSO lets a user log in once and move across all of them seamlessly, while authentication stays centralized. This pairs naturally with Drupal's multisite architecture, where many sites are governed from one place.
- The identity lifecycle: A person's relationship with a university changes over time — applicant, student, graduate, and sometimes staff — and their access needs change with it. Driving Drupal roles from the IdP's attributes means access can follow that lifecycle automatically, rather than being manually adjusted at each transition.
- Distinct populations: Students, faculty, staff, and alumni often need different levels of access to different systems. Because the IdP reports group membership, Drupal can map each population to the appropriate role automatically, keeping permissions aligned with a user's actual status.
These scenarios are exactly why identity integration is a core part of building a university platform rather than an afterthought. They also connect to the broader academic integrations a Drupal site typically needs — a learning platform among them, which we cover in our guide to Moodle and Drupal integration.
Common SSO Mistakes and How to Avoid Them
- Running local accounts alongside the IdP: The most common governance failure. Independent Drupal accounts drift, don't deprovision, and accumulate weak passwords. Route authentication through the IdP and keep only a break-glass admin account local.
- Forgetting the break-glass account: If every login depends on the IdP and the IdP becomes unreachable, no one can get in — including administrators. A single, well-secured local emergency account prevents a total lockout.
- Mapping roles carelessly: Automatically granting elevated Drupal roles from IdP attributes can hand out administrative access unintentionally. Map each attribute to the least privilege it needs, and treat administrative roles with extra scrutiny.
- Ignoring deprovisioning: Focusing only on getting login to work leaves the more important question — how access is removed — unanswered. Design for the moment someone leaves, not just the moment they join.
- Choosing a protocol in isolation: Picking an SSO technology without checking what the institution already runs leads to unnecessary complexity. Start from the existing identity provider and connect to it.
- Neglecting attribute mapping: If the IdP's attributes aren't mapped correctly to Drupal fields and roles, users can log in but land with the wrong permissions. Confirm the attribute mapping as carefully as the login flow itself.
Done properly, SSO integration makes a Drupal site a seamless, secure part of a university's digital ecosystem — one identity, centrally governed, spanning every connected system. It's a foundational capability for any institution running Drupal at scale, and it's part of the wider set of academic integrations explored in our overview of Drupal in education.
Frequently Asked Questions About Drupal SSO
Does Drupal store passwords when SSO is enabled?
No — that's the core security benefit of SSO. When authentication is delegated to an identity provider, user credentials are verified by the IdP and are never stored in Drupal. The recommended configuration disables local password authentication entirely, except for a single break-glass administrator account kept for emergencies. This means passwords, password policy, and multi-factor authentication all live in the institution's central identity system, and Drupal simply trusts its verified response.
Can Drupal use more than one identity provider at once?
Yes, depending on the modules used, Drupal can be configured to work with multiple authentication sources. A common example is an institution that authenticates students through one system and staff through another, or that maintains SAML for most users while keeping a limited local option for a specific group. The configuration grows more complex with each source, so the practical advice is to support only the identity providers there's a genuine need for, and to keep the setup as simple as the institution's real requirements allow.
What's the difference between authentication and provisioning?
Authentication is verifying who a user is — confirming their credentials against the identity provider. Provisioning is creating and maintaining the user's account and attributes in Drupal. SSO handles authentication; just-in-time provisioning handles the account creation that follows, generating a Drupal account automatically on first login and populating it from the IdP's attributes. They work together: authentication proves identity, and provisioning gives that identity a place and a role within Drupal.
Is SAML or CAS better for a university?
Neither is universally better — it depends on what your institution already runs. SAML, including its academic implementation Shibboleth, is the right choice for institutions in research federations or standardized on identity platforms like Entra ID or Okta. CAS is a strong fit for universities that already operate a campus-wide CAS server. The decision should follow the existing identity infrastructure rather than an abstract ranking: connect Drupal to the system your institution already trusts, and let that determine the protocol.