Page History

eduID.at installation guide for the Shibboleth IDP

...

5

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 installtion installation instructions if you're determined to use Apache httpd (which is also possible, but sufficiently 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.

...

1. Install and configure Java and Tomcat as webserver with TLS/SSL support, running Tomcat and the JVM as non-root user
2. Install the Shibboleth IDP software and integrate it with Tomcat
3. Load SAML Metadata using the eduID.at Metadata and eduID.at Metadata Verification Key
   • For new eduID.at members: Send a copy of your IDP Metadata (by default 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.
     
4. Configuring authentication & attribute lookup and generation is somewhat site-dependent although we strive to provide examples usable by most eduID.at members.
5. Configure attribute release filters, including controlled, scalable attribute release based on Service Categories

...

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:

• Adjust Logging
• 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 make 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 a privacyIDEA instance plus the neccessary integration software for the Shibboleth IDP
• OpenID Connect (OIDC) support, for (local, bilateral) services no longer offering SAML 2.0 WebSSO
• Proxying authentication to an external IDP service