Shibboleth is the IdP you choose when you need bulletproof privacy controls and don't want to pay Okta's ransom fees. Version 5.1.6 dropped on August 26, 2025, patching a CAS security hole and fixing CVE-2025-41242 in Spring Framework - because nothing says "fun Monday" like a path traversal vulnerability.
Single sign-on that actually respects user privacy. Your users log in once, get access everywhere, and you control exactly what information each app sees. Novel concept, I know. Built on SAML 2.0, Shibboleth signs identity assertions cryptographically so service providers can trust the data.
Technical Architecture and Core Components
Fair warning: Shibboleth configuration is XML-based. If you hate XML, you're going to hate your life for the next few months. The config files are verbose and unforgiving - one missing namespace declaration and nothing works. That said, it's a Java web app that plugs into whatever identity store you already have: LDAP, Active Directory, or databases.
Authentication Subsystem: Handles password auth, MFA, and external auth delegation. "Highly configurable" is marketing speak for "you'll spend three weeks debugging authentication flows that work fine in dev but explode when Janet from Accounting tries to log in." Start with basic password auth or you'll hate yourself.
For example, a typical MFA flow might require password authentication followed by Duo Security push notifications for administrative users, but only password auth for regular users accessing low-risk applications. The flow definitions are Spring WebFlow XML that will make you question your life choices - here's what a simple password-then-MFA flow looks like in the config:
<flow xmlns=\"http://www.springframework.org/schema/webflow\">
<action-state id=\"initializePasswordAuthentication\">
<evaluate expression=\"initializePasswordAuthentication\" />
<transition on=\"proceed\" to=\"checkForDuoMFA\" />
</action-state>
<decision-state id=\"checkForDuoMFA\">
<if test=\"requestScope.requireDuo\" then=\"displayDuoForm\" else=\"proceed\" />
</decision-state>
</flow>
That's the simple version. Production flows with risk-based authentication and multiple fallback options can run 200+ lines of XML.
Attribute Resolution and Filtering: This is Shibboleth's killer feature and also its complexity source. You can pull user data from multiple sources and control exactly what gets released to each service. Getting attribute release policies wrong means either leaking user data or breaking applications. There's no middle ground.
Here's a real-world example: you might want to release a user's email and display name to Google Workspace, but only release an anonymous persistent ID to a third-party research tool. The attribute filter policy looks like this:
<AttributeFilterPolicy id=\"GoogleWorkspacePolicy\">
<PolicyRequirementRule xsi:type=\"Requester\" value=\"https://accounts.google.com/o/saml2\"/>
<AttributeRule attributeID=\"email\">
<PermitValueRule xsi:type=\"ANY\"/>
</AttributeRule>
<AttributeRule attributeID=\"displayName\">
<PermitValueRule xsi:type=\"ANY\"/>
</AttributeRule>
</AttributeFilterPolicy>
<AttributeFilterPolicy id=\"ResearchToolPolicy\">
<PolicyRequirementRule xsi:type=\"Requester\" value=\"https://research.university.edu/saml/sp\"/>
<AttributeRule attributeID=\"persistentID\">
<PermitValueRule xsi:type=\"ANY\"/>
</AttributeRule>
<!-- No email or name attributes released -->
</AttributeFilterPolicy>
Miss a single XML namespace or mistype a service provider entity ID and you're fucked. Spent two weeks debugging this nightmare where SAML looked fine but apps kept saying 'user not found.' Turns out someone typo'd the entity ID. In production. On a Friday afternoon. Because of course.
Protocol Support: SAML 2.0 is the main event, but you can bolt on OpenID Connect via plugin if you need OAuth 2.0. The OIDC plugin works, but it's not as polished as native SAML support.
System Requirements and Platform Support
The v4 to v5 upgrade isn't just a software update - it's a full infrastructure migration. The Java 17 requirement means you'll be upgrading your entire servlet container stack. Budget a weekend for this:
- Java 17: Use Amazon Corretto 17 or Red Hat OpenJDK 17. Debian's OpenJDK 17 broke our SSL handshake with some TLS 1.3 garbage that made zero sense. Three days of Wireshark dumps later we figured out it was trying to use some cipher that nobody supports.
- Servlet Container: Jetty 11+ or Tomcat 10.1+. Jetty is what the Shibboleth devs actually test against, so use that unless you enjoy being a beta tester.
- OS: Anything that runs Java 17, which sounds flexible until you realize half your infrastructure is still on Java 8.
Half the Internet is still running Java 8 servlet containers. If that's you, budget three months for the v4→v5 migration. We thought we were smart upgrading incrementally - still found three showstopper issues in production.
Privacy and Security Features
This is where Shibboleth shines compared to commercial IdPs that treat user data like a commodity. While Okta will hand over user data to any SaaS vendor with a credit card, Shibboleth makes you work for every piece of user data:
Attribute Release Control: You configure exactly what gets shared with whom through attribute filtering policies. Want to share email but not phone number? Easy. Want to release GPA only to academic services? Done. Good luck getting that granular control from commercial providers without paying enterprise fees.
Targeted Identifier Generation: Instead of exposing real usernames, Shibboleth generates unique identifiers per service. Users can't be tracked across applications even if providers collude. This was built for FERPA compliance but works for any privacy-conscious deployment.
Consent Management: Built-in consent screens show users what's being shared before authentication completes. Unlike those bullshit "accept all cookies" banners, these actually let users make informed decisions.
These features aren't academic fluff - they're why universities chose Shibboleth over commercial alternatives. Now that everyone cares about privacy, these capabilities are table stakes for any serious identity deployment.
But how does Shibboleth actually stack up against the competition? The answer depends on what you prioritize: control and privacy versus ease of deployment.