Shibboleth Identity Provider 2012 Upgrade: Difference between revisions
(Link to local upgrade instructions) |
m (typo) |
||
| Line 9: | Line 9: | ||
will be known to each other. This is achieved by their exchanging a | will be known to each other. This is achieved by their exchanging a | ||
block of 'SAML metadata' about themselves. This contains information about | block of 'SAML metadata' about themselves. This contains information about | ||
what services they offer, what URLs | what services they offer, what URLs they use, and what cryptographic keys | ||
they use. It's usual for IdPs to reject authentication requests from entities | they use. It's usual for IdPs to reject authentication requests from entities | ||
they have never heard of. One of the reasons for [[SP registration|registering an SP]] (in the local 'Ucam Federation' or the the UK federation) is to arrange for this metadata to be distributed as needed. | they have never heard of. One of the reasons for [[SP registration|registering an SP]] (in the local 'Ucam Federation' or the the UK federation) is to arrange for this metadata to be distributed as needed. | ||
Latest revision as of 13:01, 17 July 2012
- See Identity Provider 2012 Upgrade progress for an update on the progress of this upgrade, known poblems, etc.
- See Identity Provider 2012 Upgrade local instructions for what local Shibboleth users need to do to transition to the new service.
As announced elsewhere we will be upgrading the Shibboleth Identity Provider (IdP) component of Raven between June and August 2012. This upgrade will not affect the Raven service provided over the older 'Ucam WebAuth' protocol.
This upgrade represents a significant change to the software in use at the Raven end which always opens up the possibility of unexpected failure. It also introduces a significant change to the current service and administrators of some web servers using Shibboleth (Shibboleth Service Providers, or SPs) will need to make some configuration changes to match.
The significant issue here is that, in the Shib world, there's an expectation that all cooperating SPs and IdPs will be known to each other. This is achieved by their exchanging a block of 'SAML metadata' about themselves. This contains information about what services they offer, what URLs they use, and what cryptographic keys they use. It's usual for IdPs to reject authentication requests from entities they have never heard of. One of the reasons for registering an SP (in the local 'Ucam Federation' or the the UK federation) is to arrange for this metadata to be distributed as needed.
It is however possible to configure the Shib software that we are currently running to accept authentication requests from servers that it has never heard of ('anonymous requests'), and our current IdP is so configured. Several local SPs are relying on this.
This isn't an option in the new software, and even if it were, newer features of the protocols won't work without prior registration so there would be little point trying to enable it. This means that any SP that hasn't registered will need to do so before it will be able to interwork successfully with the new Raven Shib server.
Fortunately it's possible to run the old and new Shib servers in parallel. Which version of the service any particular SP will talk to will depend on the IdP metadata that they load. Because of conflicting timing requirements we'll deploy this upgrade in two phases.
We expect to deploy the first phase during the week beginning 18th June. For this we will update the metadata describing our IdP as distributed by the UK federation to point to the new service. This will mainly affect external resources such as electronic journals, but it may affect a small number of sites inside the University. SPs probably shouldn't be using the UK federation metadata file unless they are registered in that federation so this change shouldn't cause problems. SPs affected by this phase will be loading SAML metadata from http://metadata.ukfederation.org.uk/ukfederation-metadata.xml (see the 'MetadataProvider' element in shibboleth2.xml if using the Internet 2 Shibboleth SP software). The timing of this phase is constrained by the need to choose a time when use of external electronic journals is low.
The second phase will involve all other servers using Shibboleth or SAML software to authenticate to Raven, and will run from June to August. During this period, the Raven IdP will publish two different versions of the metadata about itself: the current one (from https://shib.raven.cam.ac.uk/ucamfederation-idp-metadata.xml) will continue to direct SPs to use the current (old) service, and a seperate set of metadata will direct SPs to use the new service. SP administrators will be able, in their own time, to register if necessary and then switch to the new service by switching their metadata source and then testing as necessary. In case of problems they can easily revert. We will do our best to contact the administrators of all the affected services, but this does depend on our being able to identify appropriate contacts. Sometime in September the old service will be decommissioned, at which point any server that haven't transitioned will loose service.
Announcements, including updates on progress and arrangements for testing access to the new service ahead of the various changes, will be made to the cs-raven-announce mailing list only. Administrators of any server using Shibboleth within the University are very strongly encouraged to subscribe to this low-volume mailing list. You can subscribe at https://lists.cam.ac.uk/mailman/listinfo/cs-raven-announce. Questions related to the Raven service and this upgrade should be addresses to raven-support@ucs.cam.ac.uk.
