Configuring other Shibboleth SPs

We're working on improving Raven resources for developers and site operators.

Try out the new Raven documentation for size.

Most of the instructions in this wiki relate to getting the Shibboleth Consortium's SP software to work with Raven's Shibboleth/SAML IdP. It's possible to get the Raven Shibboleth service to inter-work with most standards-conforming SAML SPs, though custom configuration and possibly some in-depth knowledge of SAML may be needed. Raven Support has some experience of doing this and may be able to advise.

This document covers some of the issues you may encounter.

Metadata

You will need to register your SP with Raven by uploading suitable metadata to the Shibboleth Metadata administration site. Hopefully your SP or service supplier can provide this. Otherwise you may need to write it from scratch. See SP registration for how the upload process works and for some advice on changes you may need to make to supplied metadata to make it acceptable to Raven.

Attributes

Some SPs may want or require attribute and/or attribute values that Raven doesn't normally release, or which Raven doesn't have. See Attributes released by the Raven IdP for a summary of what's currently possible. Note that attribute values not normally released to SPs outside the University can sometimes be released by arrangement. Contact Raven Support if you need this.

A common problem is SPs that require 'forename' to be released (often along with 'surname' and 'mail address'), because Raven doesn't have access to forename information. A sometimes useful workaround is to use 'initials' in place for forename.

nameIDs

SAML authentications contain a single 'nameID' that in some way identifies the individual being authenticated. A number of different formats of nameID are defined, corresponding to different symantics.

The Raven default, matching normal 'Shibboleth' usage, is to use the 'transient' nameID format. This creates a random string that identifies each authentication transaction but which doesn't (except by reference to log information) directly identify the person being authenticated. In normal Shibboleth usage, nameID is largely ignored in favour of information provided in attributes.

Service URLs

Helpful SPs discover everything they need to know to interact with Raven from the Raven Shibboleth service metadata, a copy of which is available at https://shib.raven.cam.ac.uk/shibboleth for the production service and https://shib-test.raven.cam.ac.uk/shibboleth for a debugging test instance. However some expect the relevant service URLs to be configured manually. All the necessary URLs appear in the IdP metadata, but selecting the right one may require an understanding of how both SAML and the SP in questions works.

If your SP wants to use the SAML 2.0 HTTP-POST binding use:

 https://shib.raven.cam.ac.uk/idp/profile/SAML2/POST/SSO

If your SP wants to use the SAML 2.0 HTTP-Redirect binding use:

 https://shib.raven.cam.ac.uk/idp/profile/SAML2/Redirect/SSO

Encryption Keys

SPs need to have the public key corresponding to the private key that the Raven IdP uses to identify itself and to encrypt things. Again, helpful SPs get this from the Raven Shibboleth service metadata where it appears in a self-signed X.509 certificate. Unfortunately the format in which it appears in the metadata isn't quite the format that most software will expect.

For convinience, the keys currently used appear below:

Production service on shib.raven.cam.ac.uk (expires Nov 17 14:50:51 2025 GMT):

Debugging/test service on shib-test.raven.cam.ac.uk (expires Dec 2 11:56:44 2022 GMT)

Configuring other Shibboleth SPs

Contents

Metadata

Attributes

nameIDs

Service URLs

Encryption Keys

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

Tools