...
| Note |
|---|
Be aware that Java typically relies on a blocking PRNG by default, and the IdP may be observed to start up very slowly if there is insufficient entropy available. There are various workarounds or ways to install better sources of entropy by altering jre/lib/security/java.security or using system properties, but they are platform-specific. |
| Note |
|---|
Deploying the IdP under Java 17 is possible from version 4.1.0 onwards, but Use of JavaScript-based scripting requires the installation of an IdP plugin such as Nashorn, see PluginInstallation. This is necessary to compensate for the removal of the JavaScript engine from all supported versions of Java 15+.The requirement for a JavaScript plugin will be removed starting with IdP version 4.2.0, but many deployers will choose to install such a plugin in any case. This is not required to install the IdP but is often required when configuring various advanced features without use of Java directly. |
See the SecurityAndNetworking page for introductory help in understanding the use of network ports, keys, and certificates.
A nice cross-platform GUI for manipulating Java keystores, PKCS#12 files, viewing certificates, etc., is Keystore Explorer. Most deployers, at least on Linux, tend to rely on OpenSSL’s command line for many such tasks.
Before you begin you should collect the following items and information:
...
the entityID URL you want to use to name your IdP (the installer will suggest one from your hostname, but this may very likely is not be a good choice)
the second- or third-level DNS subdomain to append to any "scoped" attributes, often the same as your organization's email domain
a source of SAML Metadata for the service providers your IdP needs to support (this could come from a "federation" of organizations you've joined, directly from the SP owners, or created and maintained by hand)
| Note |
|---|
If you don't have any SAML metadata to give the IdP, you won't have an easy time making it do anything useful without changing a lot of defaults, so please take the time and start by acquiring or creating that metadata first if you're just starting out. While the IdP is functional and testable using the Hello World feature, any “real” testing of SAML will require metadata. If you have nothing else to use, the SAMLtest.ID site can help you get started, but if you're using it longer than a couple of weeks, you should rethink what you're trying to accomplish, and consider installing your own SAML Service Provider for testing (it does not need to be our implementation of course). |
The installation process will suggest or generate the following information for you:
...
As noted, the IdP is a standard Java web application based on the Jakarta Servlet 35.1 0 specification and should run for the most part in any compatible servlet container, but official support is provided only for Jetty and Tomcat. Jetty is the strongly recommended option and is used by the primary team members in their production environments. As noted in the SystemRequirements , the Jakarta Servlet API is supported only by “later” containers as it is incompatible with the older long-time Java Servlet specifications.
Containers for which we have specific installation guidance are shown in step 1 below, including some that we do not officially support. Material specific to any container is provided as a convenience, and is not a substitute for the container's own documentation.
Prepare your Servlet container. Linux deployers may want to take a look at the old IdPLinuxNonRoot topic, which documents one way of using privileged ports. Some containers, such as Jetty, include alternatives. The links below are to (imperfect) examples provided by the project or by deployers. The list below is not reflective of the specific containers and versions we support, which is explicitly and only available on the SystemRequirements page.
...
...
Download the latest Identity Provider software package (the zip file has Windows line endings, the tarball Unix line endings).
Unpack the archive you downloaded to a convenient location. It will not be needed after installation.
Change into the newly created distribution directory, shibboleth-identityprovider-VERSION.
Run either bin/install.sh (on non-Windows systems) or bin\install.bat (on Windows systems).
The installation directory you provide will be referred to as
idp.homethroughout this documentation.The installation directory cannot be the source directory.
Deploy the IdP WAR file, located in war/idp.war. See the Servlet container preparation notes for examples on how to do this.
Property Driven Installation
...
| Code Block | ||
|---|---|---|
| ||
./bin/install.sh -Didp.keysize=2048 |
It is also possible to write Java code to drive the installation process
...
If everything is working correctly, you should see output summarizing the environment and information about the IdP's state. This doesn't mean that you will be able to log into anything yet as you have not yet configured the IdP to use your organization's infrastructure, added metadata, etc.
Typical Next Steps
Review the top of the Configuration page to get some basic familiarity with the installation tree and how to use it.
Configure authentication.
Configure attribute resolution.
Try the Hello World feature for initial testing of authentication and attribute resolution.
Load SAML metadata for the service provider(s) with which you will interact and establish an appropriate attribute release policy.
Customize your login UI, error handling, etc.
Rebuilding the WAR file
To rebuild the WAR file, run the build command line utility (bin/build.sh or bin\build.bat) from the installation directory idp.home. Properties available are documented here.
...
| Code Block |
|---|
.\bin\build.bat -Didp.target.dir="C:\Program Files (x86)\Shibboleth\IdP" |
Installing Plugins
...
Various extensions are also provided as plugins. IdP plugins are installed and interrogated using the plugin command line (bin/plugin.sh or bin\plugin.bat). See PluginInstallation for more details.
...