Fri, Jan 25, 2008
We’re currently using the Shibboleth to Athens gateway in production, which lets us login to My Athens using our institutional credentials and it’s all fine and dandy. Shibboleth seems to work just fine and the users have set up their ecosystems in the various dynamic services such as RefWorks. The community were of the opinion, helped along by JISC information, that the gateways would be funded up until 2011. So there would be no need for a financial outlay in using the gateways until then. Or so we thought.
Negotiations have now broken down and JISC have announced that the gateways will not now be funded after July 2008. Instead, institutions, to maintain their Athens access, will have to subscribe to OpenAthens to keep using the Shibboleth to Athens gateway. Eduserve have some blurb on the situation here.
JISC are keen that no institutions will have to pay for commercial access to their resources and have touted the UK Federation as an alternative method for accessing resources that were previously accessed via Athens. There’s an impressive list of suppliers listed here but although some suppliers are listed, they’re not available via Shibboleth, which means they must be accessed via Athens to provide continuity of service. Which means having to pay for access, which JISC said institutions wouldn’t have to do. However, JISC are working on an interim solution for this, which I await with interest.
But there’s a far darker side to “just changing” the way you access a resource. Take for example RefWorks. The Shibboleth to Athens gateway uses eduPersonTargetedId to transfer “state” information for a user. In effect, this is a “personalisation” attribute whose value, according to the eduPerson spec, should only be used with one Service Provider (SP) or a group of Service Providers. The group is significant here, as we’ll see. If an institution decides not to pay for OpenAthens access and instead go for direct Shibboleth access to RefWorks, via the UK Federation, they should be aware of the consequences of changing the value of eduPersonTargetedId. RefWorks behind the Shibboleth to Athens gateway inherits the entityId of the gateway:
but RefWorks as a Shibboleth Service Provider in its own right will have a different entityId. It cannot have the same entityId as the gateway. If an Identity Provider (IdP) is working on the assumption that the value eduPersonTargetedId should not be shared among SPs, then the value will change depending whether you login to RefWorks via the Shibboleth to Athens gateway, or direct via Shibboleth. This would be fine for a static resource, such as a collection of eBooks. The problem arises if you’re accessing a “dynamic” resource, such as RefWorks, where you can setup references, which are keyed against the “account” you are issued with, when you login to RefWorks. That “account” is determined by the value of eduPersonTargetedId.
So you’ve been accessing RefWorks via the Shibboleth to Athens gateway for the last year and setup 100+ references. The institution in the meantime has been researching how to migrate this personalisation information to direct Shibboleth access via the UK Federation, having until 2011 to do so. Suddenly and without warning, JISC and EduServe part company and the institution only has 6 months to sort it. If the institution decides to not subscribe to OpenAthens all hell may break loose unless the use of eduPersonTargetedId is understood.
OpenAthens doesn’t provide continuity of access. It does, yes but it more importantly provides continuity of “state”.
Unless an institution uses the same value of eduPersonTargetedId with certain SPs within the UK Federation as it does with the Shibboleth to Athens gateway, all those 100+ references are going to disappear. The user will use the same username and password to login, as both access methods use Shibboleth but as the value of the personalisation attribute (eduPersonTargetedId) has changed between Athens and RefWorks direct, the user will be asked to re-register and will lose access to all their references. The only way to get to them is to login to RefWorks via the Shibboleth to Athens gateway.
So the same identity has different profiles depending on how the user accessed the resource. Login to RefWorks via Athens, 100+ references. Login via RefWorks direct, nothing.
So, working within the eduPerson spec for eduPersonTargetedId, an institution would be wise to use the same value between the Shibboleth to Athens gateway and SPs with dynamic content, to preserve state across access methods. This would constitute a migration bridge between Athens and the UK Federation.
The alternative is helpdesk meltdown.