Quelle anzeigen

eduID.at installation guide for the Shibboleth IDP 5

The following is an example of a complete set of instructions for the installation and basic configuration of a current Shibboleth 5.x IDP on Debian 12 ("Bookworm"), using Java 17 and Tomcat 10.1.x as provided by Debian.

Debian provides deployers with a stable and well-maintained platform offering ongoing security fixes, does not require any licensing/purchansing and comes at no cost. We know of no other platform/OS/distribution that comes with all these benefits.

Unfortunately Ubuntu is no longer a viable platform for deploying the Shibboleth IDP (or anything else that requires secure operation, for that matter): It has become evident that Ubuntu does not provide security updates for Tomcat 10.1.x, see e.g. the lack of available fixes for CVE-2025-24813 for Tomcat 9 and Tomcat 10. There is no point in running an OS from a vendor that does provide you with applications but does not provide you with security fixes for those applications!
Debian 12 on the other hand does and did provide security fixes for that same vulnerability for their current "stable" and previous "oldstable" releases of their OS.

See out notes on deploying the Shibboleth IDP on RHEL/CentOS for our take on the (unfortunate) status quo.

The installation instructions provided in this guide are specific to a deployment without Apache httpd, using Apache Tomcat both as Java Servlet Container and as TLS/SSL-enabled webserver. Do not follow these installation instructions if you're determined to use Apache httpd (which is also possible, but already documented elsewhere) – though you can still follow the rest of our documentation for metadata, resolver, filter, etc. configuration.

There is no point in duplicating the existing Shibboleth IDP documentation. The installation part of this guide is complete but the guide for configuration of a Shibboleth IDP is necessarily incomplete, as deployments can vary significantly and the IDP has tons of (optional) advanced features. Please use the upstream documentation for further steps or more advanced configurations, as hinted at below.

This guide is broken up into several sequential steps in order to allow simple testing: After step 1 you should have a working TLS-enabled webserver based on Tomcat. Do not move on to step 2 unless you have completed step 1 successfully. Do follow those instructions in the order given. You can always come back to other sections later.

Install and configure Java and Tomcat as webserver with TLS/SSL support, running Tomcat and the JVM as non-root user
Install the Shibboleth IDP software and integrate it with Tomcat
Load SAML Metadata using the eduID.at Metadata and eduID.at Metadata Verification Key
- For new eduID.at members: Send a copy of your initial IDP Metadata (by default available in /opt/shibboleth-idp/metadata/idp-metadata.xml) to the eduID.at Operations Team, ideally signed with your S/MIME or OpenPGP key. Or send the HTTPS URL to your IDP publishing its own SAML 2.0 metadata for a one-time import from that URL.
Configuring authentication & attribute lookup and generation is somewhat site-dependent although we strive to provide examples usable by and helpful to most eduID.at members.
Configure attribute release filters, including controlled, scalable attribute release based on Service Categories

Upstream documentation

Until more steps/topics are covered in the instructions in this wiki please refer to the upstream documentation and engage with the community:

Please make use of the eduID.at community which has been configuring and running Shibboleth IDPs for well over a decade by now! The Contact page has the details for the eduid-discuss mailing list the members of which should be able to help you with any and all problems in this space (Shibboleth IDP-related or even Identity and Access Management-related issues).

The Shibboleth Wiki has many more suggestions of what to do, esp in the IDP Configuration overview and in the Productionalization sections.
You will also want to do the following:

Customize the IDP's login page for Username/Password authentication, to match your institution's design.
Look at the Consent functionality and make a plan where/when (not) to enable/disable this
- This also relates to attribute release strategies and should be considered together with those
Adjust Logging
Consider using translated messages from the IDP software, possibly also locally adapting them as needed (de_AT, anyone?)

And of course there's an increasing number of advanced features you could be making use of, including:

Secure authentication, commonly known as Multi-Factor Authentication (MFA) or 2-Factor Authenticatiion (2FA), e.g.
- by restricting your deployment to the TOTP mechanism and providing your own UI to allow end users to register devices (or token seeds), or
- by relying on external services such as privacyIDEA or its fork eduMFA plus the neccessary integration software for the Shibboleth IDP (fudiscr or for privacyIDEA maybe the one from privacyIDEA).
OpenID Connect (OIDC) support, for local/private services not offering SAML 2.0 WebSSO support
- Integrating with local/private services over OIDC may sometimes be easier than with SAML, sometimes OIDC may be the only option.
  As such we recommend to all IDP deployers to enable the OpenID Connect Provider functionality by following the relevant documentation.
Proxying authentication to an external Identity Provider (via SAML or OIDC) may sometimes be needed in order to fulfill an organisation's "business requirements".