Shibboleth is the reference SAML implementation. We’ve been involved in the Shibboleth project from the beginning, and we’d like to optimize your Shibboleth infrastructure. This page provides some basic technical introduction to Shibboleth. Once you’re ready, please contact us and let’s get building.
Identity Provider (IdP)
An IdP has two faces: one that it shows the outside world, and one that it shows users. One is your IdP’s own metadata, and the other hopefully the login page. There’s also a phenomenal amount of back-end plumbing into other identity infrastructure that most commonly hosts user data or remotes authentication.
The login configuration is unfortunately very complex due primarily to strict adherence to restrictions in the specification. We recommend always using the MFA handler even if you just need passwords today, as it’s the general solution that positions you for the future. We also recommend avoiding AuthnContextClasses to the extent possible.
Branding and theming the login page and user ID well is crucial. It’s a juicy target for phishers and screen scrapers, and users need to feel confident that they are entering their credentials at the right place. User education and internal communication campaigns also play a big role.
Attributes and NameID’s
Attributes may be sourced from a variety of places or generated by the IdP itself. These attributes are then manipulated and transformed into the format desired by the relying party. Finally, a set of attribute filters is applied that selectively releases information to services based on your rules.
There is a special field known as the NameID that you will need to configure frequently. NameID configuration is a challenge because the field is often misused or treated as elevated by services. We’ve found it’s best to comply with these requests, but restrict your configuration so that only that recipient gets their special version.
There are often several candidate NameID’s generated during the authentication process and the IdP has to pick one preferentially. To be available, a NameID must have any underlying attributes released to the SP. Then, the attribute must be translated into the proper NameID using
saml-nameid.xml configuration. Finally, through combining preferences expressed in the AuthnRequest and the IdP’s own configuration, the preferred candidate is selected and elevated into the Subject field of the assertion.
Your metadata file was generated using a combination of your input during installation and best guesses by the script and it is not automatically updated when your configuration changes. It is hosted by default at https://your.provider/idp/shibboleth, which is also the default entityID. You are responsible for maintaining this file to accurately reflect information about your identity provider, and you may have other editions of metadata maintained in other environments.
Your metadata is not for your own consumption, though: it’s for your partners. You’ll also need to configure your identity provider to load the metadata of all the service providers it would like to interact with and attribute release will generally always need to be configured. In some cases, that’s all that is needed to add a new service. Other integrations can get more complex.
Clustering is certainly not mandatory, but we recommend the use of Hazelcast when the deployment is of appropriate scale and persistence on node failure is not a necessity. Otherwise, sessions may be stored in a database, or with luck, entirely in the client. While back-channel calls are not frequently used by Shibboleth today, we anticipate that changing as existing features are leveraged and new protocols are added.
We understand that your hosting environment is often constrained by resourcing. Source control is basically mandatory, but you can get away with creative approaches to load balancing and deployment management. We do small and large.
CAS Protocol Support
Shibboleth was principally engineered for SAML, a specific federated identity protocol. However, many identity protocols have been successfully integrated with Shibboleth.
Specifically, Shibboleth is capable of acting as a CAS Server. If you are delegating your Shibboleth authentication to your CAS servers, you have an opportunity for consolidation.
Service Provider (SP)
The service provider is implemented as a daemon and as a native web server module for IIS and Apache. This limits the module’s memory usage and access to private keys. Along with mod_proxy_ajp and FastCGI support, almost any application can be connected to Shibboleth.
An arbitrarily complicated web hosting environment can be accommodated with the service provider, with extensive support for reverse proxying, multiple distinct applications on a single host, applications that span hosts, and clustering. Most scenarios will not need to leverage these features, but we have plenty of ApplicationOverride experience.
While integrating federated identity with an application is more art than science, a few general truths exist. There are two primary points of integration: triggering an action, like login invocation, and receiving data, which is exported as environment variables or HTTP headers. Actions are invoked with calls to special URL’s called Handlers, while any protected resource will be able to pull the received information through those variables.
Your principal action will be triggering a login, which is usually done with a redirect to https://your.provider/Shibboleth.sso/Login. Appending query string parameters changes the behavior of these actions; for instance, affixing an &entityID=https://idp.partner/idp/shibboleth will trigger direct session invocation with the provider. Getting users back to the right IdP is trivial for applications serving each organization in vacuo and an art for applications serving many in tandem.
Your SP describes itself with a metadata file. It will generate one based on its own configuration and web environment if you access https://your.provider/Shibboleth.sso/Metadata. Because the generator can’t know everything about your hosting environment, this file is the basis for modification to reflect the public face of your SP. Many providers use it untouched anyway.
Your SP will also need to load the metadata of the IdP’s that it trusts. This can be done through multiple trust models and is discussed more deeply in the SAML section.
Protecting content can be done by the application itself, Apache’s native access control mechanisms, or by using a policy language in shibboleth2.xml itself. This is in descending order of preference, but the overriding factor is what is most natural for your hosting environment.
All these mechanisms access user data and compare it to rules through variables and matching clauses. Additional variables about the session, the IdP used, and other information is also exported for use.
One of Signet’s team members is very proud to be emeritus in Shibboleth’s CREDITS.txt.