Versions Compared

Old Version 13

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version Current

changes.mady.by.user Scott Cantor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • a TLS key/certificate that you'll use to secure your browser-facing HTTP(S) connection on port 443 (this is just a plain old low cost or even free commercial TLS certificate)

Assuming you plan to use the IdP for SAML support (as opposed to CAS support for example), you will need:

  • the entityID URL you want to use to name your IdP (the installer will suggest one from your hostname, but this 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 the source(s) 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

To the latter point, if you don’t have metadata, just proceed while understanding that to make the IdP aware of an SP and support using it, you’ll eventually need metadata for each SP you want to connect to. 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:

  • the IdP's entityID (which you can override as noted above)

  • separate self-signed key/certificate pairs for:

    • message signing

    • securing web service connections, generally on port 8443

    • encryption of data by other systems for decryption by the IdP

  • a secret key and key version file for securing cookies and other data produced by the IdP for its own use (this is a special Java keystore of type "JCEKS")

  • some initial sample metadata describing the IdP for use by partner SPs, once it's reviewed and supplemented

  • a default set of IdP configuration files based on this information

...

  1. 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.

  2. Download the latest Identity Provider software package (the zip file has Windows line endings, the tarball Unix line endings).

  3. Unpack the archive you downloaded to a convenient location. It will not be needed after installation.

  4. Change into the newly created distribution directory, shibboleth-identityprovider-VERSION.

  5. 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.home throughout this documentation.

    • The installation directory cannot be the source directory.

  6. Deploy the IdP WAR file, located in war/idp.war. See the Servlet container preparation notes for examples on how to do this.

...

Command line options 

The install.sh & / install.bat scripts support a limited number of command line options. The idp.conf.preoverlay and idp.initial.edit-webapp property files are no longer supported.

Expand
titleCommand Line Options

Option

Description

-t
--targetDir

This is either the location of an existing install (to be upgraded) or where to put a new install.

--noPrompt

If set to true then an installation will fail rather than prompt for a missing property.

--propertyFile

see PropertyDrivenInstallation

-h
--hostName

DNS name of IdP Host.

--scope

Scope that the IdP will assert

-e
--entityID

Entity ID of the new IdP

-kp
--keystorePassword

Password for the generate Key Store. If a password is not specified and random string of characters is generated.

-sp
--sealerPassword

Password for the generated Data Sealer. If a password is not specified and random string of characters is generated.

-hc
--http-client

The bean name of an http client to use (for Module and Plugin) operations

-hs
--http-security

The bean name of an HttpClientSecurityParameters to use

The idp.conf.preoverlay and idp.initial.edit-webapp properties are no longer available.

A Quick Test

You can test that the IdP is properly installed and is at least running successfully in the container with the status command line utility (bin/status.sh or bin\status.bat).

...

  1. Review the top of the Configuration page to get some basic familiarity with the installation tree and how to use it.

  2. Configure authentication.

  3. Configure attribute resolution.

  4. Try the Hello World feature for initial testing of authentication and attribute resolution.

  5. Load SAML metadata for the service provider(s) with which you will interact and establish an appropriate attribute release policy.

  6. 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.

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.

Rebuilding the WAR file

Installing plugins automatically performs this step, but should you need to rebuild the WAR file yourself, you can run the build command line utility (bin/build.sh or bin\build.bat) from the installation directory(idp.home).