IdP installer for Active Directory

The installer can be found at the Shibboleth IdP download site. The current version (as of December 08) is based on 1.3.3.

This installer simplifies the installation of a Shibboleth 1.3 IdP that uses Active Directory. Active Directory will store all user information, including attributes and authentication. Shibboleth will decide which attributes to send to which SP's and whom to trust.

The single MSI file contains all the packages needed to deploy a simple IdP against Active Directory and some specific configuration. The resulting IdP can talk to either TestShib or the UK federation. By default, it only releases two attributes. However it generates a further three (which include the UK federation core attributes).

This package has to be installed on a windows machine which is enlisted in the Active Directory domain from a suitably privileged domain account.

When you install the package you are prompted for 7 pieces of information in 2 panes. The defaults for these values assume that the installer is being run on the Active Directory server.

The first pane asks for the following information. You will usually only change the second and third values.

• Active Directory Domain: This defaults to the domain that the current user is logged into.
• DNS Name for this IdP.
• Scope: This value is used as the @school.ac.uk part of an automatically generated user@school.ac.uk that can be sent to SP's.
• Kerberos DNS Name and port.
• LDAP DNS Name and port.

In the Custom pane you can change:

• Where the install is to go.
• Whether to suppress opening of the IdP ports at the personal firewall on this machine.
• Whether or not to automatically download the UK federation metadata.

The installation will then occur, and at the end, a "next steps" web page is displayed.

Testing with TestShib

• Go to TestShib at https://www.testshib.org/
• Choose TestShib Original.
• Go to Login and create a new entity. You do not need to download any data. We will replace the data on Testshib with that generated by the installer.
• Edit the new entity, choosing "edit XML".
• Delete all the XML presented to you and paste in the contents of the "metadata-segment.xml" file in the IdP\etc directory.
• Go to http://sp.testshib.org and enter the entity name chosen for you displayed on the next steps page.
• After a certificate warning, you will hit a login page on your IdP. After logging in, you will be directed to the TestShib SP, where you should verify that member is your Affiliation and member@yoursite is correct.
• Congratulations! Your new IdP and the Testshib SP are now aware of each other and you could experiment with further attribute release using Testshib. Otherwise, it's probably time to build up to a real deployment.

Next steps

Attributes

As installed, the IdP generates eduPersonAffiliation, eduPersonScopedAffiliation, eduPersonTargetedID and eduPersonPrinicipalName but it only releases the first two. You should review resolver.xml and arp.xml and make changes appropriate to your environment as detailed in here and here.

HTTPS certificate for the SSO port.

As installed, this is protected by a self signed certificate and so anyone logging in will see a certificate warning. You need to change the tomcat installation to use a CA signed certificate. Edit CaptiveTomcat5\conf\server.xml, making the appropriate changes (KeyStoreFile, KeyStoreType) for the 8442 port.

Firewalls

The IdP needs to be visible on ports 8442 and 8443. By default, the installer sets up the personal firewall on the host machine. Dependent on your local infrastructure, you may need to make the other NAT or firewall changes.

Metadata

The installer generates a metadata segment for the IdP and places it in IdP\etc\Metadata-Segment.xml.

Other Federations

If you selected it, the metadata for the UK federation is automatically downloaded and updated. Enough metadata to allow testing with TestShib is also included. If you wish to put the IdP into other federations, you will need to arrange to download and update it as described here.

Bugs

As with all Shibboleth software support is on a best effort basis. Please report any issues to the shibboleth-users@internet2.edu mail list.

Known issues

It is a known issue that the installer does not remove all files correctly, and does not stop all the scheduled tasks. However after an uninstall the installer can be re-run and no services will be left active and there is no detritus in the registry.

What the Installer does.

The installer actually deploys and configures 3 packages:

Java

A private copy of Java 1.5 is installed under the CaptiveJava. As described here the DelegateToApplication trust engine is also installed.

Tomcat

A private copy of Tomcat 5.5 is installed. In this case the configuration is more complex:

• It is configured (via JAAS) to do login search via Kerberos (to the KDC specified during installation)
• All pages are login protected (to allow debugging of this separate from the Shibboleth Install)
• Only two ports are declared, both HTTPS and protected by a self signed certificate. The 8442 is suitable for use as an SSO endpoint. The 8443 is suitable for ACS/Artefact processing (it requires client Authentication via the DeleteToApplication trust engine.

Shibboleth

The shibboleth install is relatively standard, but resolver.xml has been specifically targeted against the Active Directory (via LDAP), and concentrates on the four "core attributes" as defined by the UK federation.

• eduPersonScopedAffiliation. As installed this is statically defined to "member@scope". This allows testing prior to getting the LDAP connection working. An example script to "mine" the ActiveDirectory "memberOf" attribute is supplied
• eduPersonPrincipalName. As installed this is not released. It is derived from the Active Directory "NT User Name" (SAMAccountName).
• eduPersonTargetedID. As installed this is not released. It is defined as a calculated Id, using the PID as per user input and a GUID as seed.
• eduPersonEntitlement. As installed this is not derived. A scriptlet example is supplied.
• A generic forms based authentication is installed.

The shibboleth distribution directory is left intact after the installation. The following files differ from the standard release and need to be preserved across software updates

• build.properties
• bin/metadataool.bat and bin/resolvertest.bat
• src/conf/dist.idp.xml, src/conf/resolver.xml, src/conf/arps/site.arp.xml (you will edit this latter two)
• webAppConfig dist.idp.tomcat2k3.xml (becomes the web.xml in the war file - controlled by build.properties)
• webApplication/login.jsp webApplication/login-error.jsp webApplication/logo.jpg