The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdPQuickInstallDetails

Owned by Rod Widdowson
Last updated: Mar 19, 2011Version comment
2 min read

Details of the Installation process.

Apache Tomcat Installation

The QuickInstaller installs Tomcat version 6.0.18 into the CaptiveTomcat 6.0 subdirectory of the installation directory. It is then configured as follows:

  • Two connectors are defined. Both are SSL protected but the one with the "Browser facing port" does not require client authentication. The "Shibboleth facing port" is configured to require client authentication and to uses the DelegateToApplication SSLImplementation.
  • The long lived self-signed certificate which the IdP Installation generates is used to protected both the "Browser facing port" and the "Shibboleth facing port". This means that during initial testing the user will see certificate errors from their browser, since the certificate was not issued by a recognized Certification Authority (CA).
  • The required libraries are endorsed for Tomcat.
  • A deployment fragment is set up for the IdP.
  • Tomcat is declared to the Windows firewall as being allowed to listen to external ports.

Much of this configuration is as described in IdPApacheTomcatPrepare

IdP Installation

The IdP is installed using a variant of the standard installation ant script. The variant is solely to allow the parameters captured above to be incorporated into the configuration files.
The configuration file templates which are used as input to the installation process have been changed as described below.

Federations

The configuration file relying-party.xml is set up to collect the metadata for the TestShib test SP only. This information must be removed before the IdP is added to any other federation. Failure to do thi would allow arbitrary SPs to impersonate testshib and thus steal user information.

Authentication

The IdP is configured to get authentication via the LDAP directory associated with the Active Directory domain. The LDAP configuration contains the extra parameterization to allow use against a Global Catalog if required (See http://technet.microsoft.com/en-us/library/cc728188%28WS.10%29.aspx).

Attributes

With the exception of eduPersonScopedAffiliation (which is statically generated), the attributes are populated from the LDAP directory associated with the Active Directory domain. The LDAP configuration contains the extra parameterization to allow use against a Global Catalog if required (See previous reference).
The IdP is configured to create three attributes:

eduPersonScopedAffiliation

The value member@scope (where scope was specified by the user) is generated.
This is released to all SPs.

eduPersonPrincipalName

The value name@scope. The scope was specified by the user and the name is populated from the sAMAccountName attribute in the directory.
This value is only released to the TestShib SP.

eduPersonTargetedID

This is generated using the ComputedId connector, using the ObjectSid attribute which has the correct uniqueness properties as input. In the SAML1 case, this attribute is encoded as both in both the old (deprecated) and new formats (see here and here).
This value is released to all SPs.