InitialIQSPConfig

Shibboleth must be installed and preliminary configuration of the appropriate webserver must already have been performed before continuing to initial configuration of Shibboleth itself. If either of those steps is unfinished, please complete it first by following the links from the main page.

Join !InQueue:

Apply for membership in InQueue by filling out and submitting the form available here. The service provider application is the bottom half of the page:

The advice in the grey boxes opposite the fields should be sufficient to complete the application.

Configure shibboleth.xml :

The configuration for the Shibboleth SP is mostly contained within shibboleth.xml , located by default at /opt/shibboleth/etc/shibboleth/shibboleth.xml . The SP comes pre-configured with certificates and settings that will work against a test !IdP running on a dummy hostname. It is also partially preconfigured for interoperation with the federation for pilot Shibboleth deployments, InQueue. The following steps below must be performed to successfully interoperate with !InQueue:

• The main Applications element's providerId attribute must be changed to reflect the URI selected for this SP when joining !InQueue. It must equal the entityID of the EntityDescriptor element in the confirmation e-mail you received from !InQueue. The new service provider will use this URI to refer to itself in all transactions with !IdP's by default. For example, if Amazon.com were running Shibboleth (stop laughing), its identifier might be https://amazon.com/shibboleth .
• Proper credentials for this target signed by an authority that the federation recognizes must be referenced by the Credentials element. Uncomment the inqueuecreds !FileResolver element and modify the contents of its Path elements to point to the Bossie certificates generated in step H.
• The supportContact and error templates for the target found in the Errors element should be changed to ensure that users have a proper support mechanism.
• Modify the default <Host> element to refer to the proper host. This must match the Apache ServerName and Port directives or the IIS Site name in the <ISAPI> element. If Virtual Hosts are being used, this should be the host on which you want to protect data for the purpose of testing. Create <Path> elements inside this <Host> element corresponding to the location to be protected. For example, to require Shibboleth for https://terror.supervillain.edu/research/shrinkray/ , you could use the following:

  <RequestMap applicationId="default">
  	 <Host name="terror.supervillain.edu">
  		  <Path name="research">
  				<Path name="shrinkray" authType="shibboleth" requireSession="true" exportAssertion="true"/>
  		  </Path>
  	 </Host>
  </RequestMap>
  

Protect a test resource on your server using a similar set of elements. To verify that everything is properly deployed and configured, you will perform a basic test by accessing this resource as a member of an InQueue identity provider.

Configure Logging:

Information in the logging configuration files referenced by shibboleth.xml may require additional changes to meet local needs. The logging level should be raised to DEBUG to provide extremely detailed information for testing. It is recommended that after initial installation is completed, the log level in both files be left at either INFO or WARN .

Access your Test Resource:

As a final step to the initial configuration, you will try to access this test resource. While any InQueue identity provider should recognize this service provider, it is recommended that Example University be used, which is a known entity provided for this purpose.

Access your resource from any web browser. If you will test from the same machine, use the full hostname rather than http://localhost . In the above example we would access https://terror.supervillain.edu/research/shrinkray/ .

You should be redirected to the InQueue WAYF, where you are from Example State University. The login page for Example State will present itself where you authenticate as demo / demo . From there, you will be redirected back to your test resource. Retrieving the resource represents success; for details of the assertion you were issued, check the Shibboleth logs.

From here the service provider should be hardened and further configured for production deployment.

%COMMENT%