Shibboleth SSO: How Federated Login Works

Note on the word itself: “shibboleth” is also an ordinary English word for a custom, password, or turn of phrase that distinguishes members of one group from another, with a well-known biblical origin (Judges 12:5–6). This guide is about the software: Shibboleth, the open-source single sign-on system that lets a researcher log in to a publisher, database, or campus tool using their home institution’s credentials. If you clicked through expecting the software rather than the word, you’re in the right place.

What Shibboleth is

Shibboleth is an open-source software implementation of federated identity management, built on the SAML (Security Assertion Markup Language) standard. In practice, it is the software that sits behind the familiar “Login via your institution” button on a publisher website, a licensed database, or a research tool: it lets a researcher’s home institution vouch for who they are, so the destination service can grant access without ever handling that person’s actual campus password.

The project originated out of Internet2 (the U.S. research-and-education networking consortium) starting around 2000, with the first Identity Provider release (Shibboleth IdP 1.0) shipping in July 2003 and a major SAML 2.0-based rewrite (version 2.0) arriving in March 2008. It is released under the Apache 2.0 license, and as of 2025 the project is managed by the Shibboleth Consortium, a membership-supported body that funds ongoing development. Because Shibboleth was one of the earliest and most widely deployed SAML implementations in higher education and research, “Shibboleth” is sometimes used loosely as a stand-in for federated SSO in general — even at institutions actually running a different SAML product — the way “Google it” outlived any one search engine.

Identity Provider vs. Service Provider

Shibboleth ships two separate pieces of software, and understanding the split is the key to understanding everything else on this page:

Identity Provider (IdP) — runs at the researcher’s home institution. It is the system that actually authenticates the person (typically against the same directory used for campus email and the library catalog) and issues a signed SAML assertion confirming who they are and what attributes about them the institution is willing to share.
Service Provider (SP) — runs at the destination: a publisher platform, a licensed database, a research tool, or another campus system that needs to know the researcher is a legitimate, currently-affiliated member of an institution before granting access.

The SP never sees the researcher’s actual institutional password. It only receives the SAML assertion the IdP chooses to release — which is precisely why what an IdP is configured to release, discussed below, matters so much in practice.

What actually happens when a researcher clicks “Login via your institution”

The researcher lands on a publisher or platform page (the Service Provider) and selects “Login via your institution,” “Institutional login,” or a similarly labeled option.
The SP needs to know which institution’s Identity Provider to send the researcher to. This is the discovery step, historically called WAYF (“Where Are You From”) — the researcher searches for and selects their institution from a list.
The researcher is redirected to their own institution’s Shibboleth IdP and authenticates there — the same login used for campus email or the VPN — or, if they already have an active campus session, the IdP recognizes it without prompting again.
The IdP issues a signed SAML assertion back to the SP confirming the researcher’s affiliation (and any other agreed attributes, such as eligible-user or faculty/student status) without necessarily disclosing more identity detail than the SP needs.
The SP trusts that assertion — because it trusts the federation the IdP belongs to, not because it negotiated a private relationship with that specific university — and grants access exactly as it would for a recognized on-campus IP address, except this time the recognition follows the person rather than the network.

Discovery, WAYF, and how this differs from SeamlessAccess

Step 2 above — figuring out which institution a researcher belongs to before the SP can redirect them to the right IdP — is a genuinely separate problem from authentication itself, and it is the specific friction point that has drawn the most product attention in this space. Historically it meant scrolling through a long, often alphabetically sorted list of thousands of institutions on every single publisher site, repeated every time, with institution names that are frequently ambiguous or duplicated.

Shibboleth itself ships a basic Discovery Service component for this step, but a separate, purpose-built layer has grown up specifically to smooth it across many publishers at once: SeamlessAccess, a multi-stakeholder initiative governed by NISO, GÉANT, Internet2, and STM. SeamlessAccess doesn’t replace Shibboleth or SAML — it standardizes the institution-finder interface across participating publishers and remembers a researcher’s institution choice in their browser, so the underlying SAML handshake (which may well be running Shibboleth software on the institution’s end) only requires that search-and-select step once rather than on every site. In short: Shibboleth is commonly the engine running the SAML authentication itself; SeamlessAccess is a discovery-and-usability layer that many publishers put in front of that engine. They are complementary, not competing, and a researcher can encounter either name depending on which piece of the flow they’re looking at.

The federations that make this trust relationship scale

A publisher or platform cannot practically negotiate a separate technical relationship with every university in the world. Research-and-education identity federations solve that by letting an SP trust an entire federation’s membership at once, based on shared technical and policy requirements for participating IdPs and SPs:

InCommon — the identity federation for U.S. research and education, operated by Internet2.
The UK federation — the identity federation for UK education and research, operated by Jisc.
eduGAIN — an interfederation service operated by GÉANT that connects national federations like InCommon and the UK federation to each other internationally, so a researcher can authenticate across borders without every country’s federation having to bilaterally trust every other one.

Shibboleth software is one of the most common implementations institutions run to participate in these federations on both the IdP and SP side, though it is not the only SAML-compliant option available.

Why federated login beats IP-based access off campus

Before federated authentication was widely deployed, most institutional access to subscribed scholarly content was recognized by IP address: a publisher’s system treated any device connecting from a university’s registered network range as an authorized user. That model works cleanly on campus but breaks down constantly off campus, on VPNs, at partner institutions during collaborations, and in any remote or hybrid research arrangement — and it has no way to confirm a specific person’s affiliation, only their network location at that moment. Federated SAML login solves this by authenticating the person directly, wherever they happen to be connecting from, rather than relying on where their traffic originates.

Common failure modes

Federated login is reliable once configured correctly, but a few recurring problems account for most of the “I can’t log in” support tickets research offices and library help desks see:

Attribute release misconfiguration. An IdP administrator has to explicitly configure which attributes get released to which SP. If the institution hasn’t approved attribute release for a particular publisher or tool, the researcher can authenticate successfully at their own IdP and still be denied access at the SP, because the SP never received the confirmation it needed.
Bookmarking the login page. A Shibboleth SP-initiated login URL typically only works when a researcher is sent to it by the originating publisher or platform, because it carries information about where to return the researcher afterward. Bookmarking the login page directly and revisiting it later is a common cause of a login that appears to “just stop working.”
Discovery/WAYF confusion. Selecting the wrong institution from a long list — especially at institutions with multiple similarly named campuses or a parent/affiliate structure — sends the researcher to the wrong IdP entirely, producing an access denial that looks like a login failure but is really a wrong-institution selection.
Stale sessions and browser state. Cached institutional-choice cookies, expired campus sessions, or switching between browser profiles can produce inconsistent behavior that looks like an authentication bug but is really local session state.

Shibboleth vs. SeamlessAccess vs. GetFTR

These three names get confused constantly because they sit in the same access chain but answer different questions:

Shibboleth is software: an open-source SAML implementation that institutions run to authenticate their own users and issue trusted assertions about them.
SeamlessAccess is a discovery and usability layer that standardizes the institution-selection step across participating publishers, sitting on top of SAML authentication that may well be running on Shibboleth (or another SAML product) underneath.
GetFTR is a separate publisher-run service that checks entitlement — whether a specific reader’s institution has rights to a specific article — at the point of discovery, before the researcher even clicks through to a publisher site.

A researcher only needs to know one thing in practice: when a site offers “Login via your institution,” clicking it starts a SAML handshake, very often running on Shibboleth software at the institutional end, that confirms their affiliation without exposing their campus password to the destination site.

Frequently asked questions

Is Shibboleth the same thing as single sign-on (SSO)?

Shibboleth is a specific open-source implementation of federated SSO, built on the SAML standard. “Single sign-on” is the broader concept; Shibboleth is one of several software products (alongside other SAML and non-SAML SSO systems) that implement it, and it happens to be one of the most widely deployed in the research and higher-education sector.

What is the difference between Shibboleth and SAML?

SAML (Security Assertion Markup Language) is the open standard that defines how identity assertions are formatted and exchanged between an Identity Provider and a Service Provider. Shibboleth is a specific software implementation of that standard — one of several products that speak SAML, not the standard itself.

What is the difference between Shibboleth and SeamlessAccess?

Shibboleth is the SAML authentication software that runs at the institution and destination service to establish trust and confirm identity. SeamlessAccess is a separate, complementary discovery-and-usability layer that standardizes the “which institution are you from” step across participating publishers; it does not replace the SAML authentication happening underneath, which may well be running on Shibboleth. See the full SeamlessAccess guide for detail on that layer specifically.

Why did my institutional login work at one publisher but fail at another?

Most often this is an attribute release problem: each Service Provider needs the institution’s Identity Provider to be explicitly configured to release the attributes that SP requires, and that configuration is done per-SP. A successful login at one publisher does not guarantee the IdP has been configured to release attributes to a different one.

Can I bookmark my institution’s Shibboleth login page?

Generally no. Shibboleth’s SP-initiated login flow is designed to be reached by clicking a link from the originating publisher or platform, which passes along information about where to send the researcher back afterward. Bookmarking the login page directly and returning to it later is a common cause of logins that appear to break for no reason.

Is Shibboleth still widely used?

Yes. It remains one of the most widely deployed SAML implementations in research and education, actively maintained by the Shibboleth Consortium, and is a common software choice for institutions participating in federations such as InCommon, the UK federation, and eduGAIN.

Shibboleth Single Sign-On: How Federated SAML Authentication Works

Ask about Shibboleth Single Sign-On: How Federated SAML Authentication Works