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
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.
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.
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).
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:
member@scope (where scope was specified by the user) is generated.
This is released to all SPs.
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.
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.