Notes: Conference call 10-2-09
Vendor subgroup minutes
Attendees:
Dean Woodbeck, Internet2
Foster Zhang, JHU
Andy Ingham, UNC
Kent Percival, Guelph
David Kennedy, Duke
Ale de Vries, Elsevier
notes - kennedy
AGENDA
Pre-reading:
https://spaces.at.internet2.edu/display/inclibrary/Best+Practices
https://spaces.at.internet2.edu/display/inclibrary/RegistryOfResources
Introductions
- including brief overview of InCommon Library Services Collaboration
Elsevier
- overview of Shibboleth implementation
- usage of Shibboleth SP software (SessionInitiators?)
- implementation of WAYFless URLs and direct links to resources
- what has or hasn't worked
Topics for discussion:
Best Practices
- are these feasible for resource providers
- do these make sense
- thoughts on how to go about making this best practice amongst resource providers
Implementation-specific question
- the URL structure for creating authenticated deep links to Elsevier platforms is rather complicated. Can this be simplified, possibly with session initiators?
What role should InCommon or the InCommon Library Services Collaboration play?
- policy setters
- documenters
- testers
- implementation documentation/assistance
Is there a desire/need for standardization across federation members' identity provider implementations that would simplify the process for resource providers' configurations?
What are we missing, especially things that you have learned from dealing with other federations besides InCommon?
NOTES FROM DISCUSSION
Kennedy gave an overview of InCommon Library Services Collaboration and vendor subgroup activities
Elsevier history and implementation
Elsevier's use of Shibboleth technology goes back quite a while to 2002/2003. ScienceDirect was one of the first SPs in the InQueue federation. Started dealing with multiple federations in 2005, predominantly in Europe. Today, deals with about 12 federations. The federations are somewhat varied in implementaions. Notable is UK federation with a lot of users and history, based on legacy Athens framework. Also noted the French federation which came up very quickly.
Also Shibboleth-enabled Scopus. ScienceDirect and Scopus both share the same authn/access management architecture. Elsevier has other platforms. They are consolidating their architecture across the company, extending Shibboleth to other platforms.
Recently upgraded to Shib 2.0.
Shibboleth provides a real challenge for Elsevier. There are several platforms to consider, and there is a tightly controlled software development process. Changes are rolled out a few times a year, so changes are not made quickly. And since the authn/access management components are central, changes are not made lightly. Also, Shib is a large operational burden for Elsevier. There is an operational burden with IP management of managing the IP addresses. But there is also a large overhead to supporting as complex of a technology as Shibboleth is.
Best Practices
#1 - Authorization via eduPerson Attributes
Completely agrees with what is stated. Federation could play a role in policy setting or enforcement of implementation. In some European federations, there is more centralized management of federations, and there is a tighter control over IdP configuration. In InCommon, it is a bit more loose, not as centrally coordinated.
Recently, due to some limitations in the design (they allowed just one eduPersonEntitlement value per federation), Elsevier turned off checking of eduPersonEntitlement for InCommon. There is a plan for upgrading the management functions to handle multiple eduPersonEntitlement values, and this will be coming in mid-2010.
This raises another interesting point about attributes. Elsevier made a core assumption in their implementation that a member of a federation is always going to be running its own IdP. In other words, there would be one EntityID per university. Based on this assumption, that is how Elsevier has done its mapping to accounts and authorizations. This has caused some problems where there are some European federations that run centralized identity providers for multiple institutions. Is this right on a philosophical level? Not sure. But anyway, a service provider cannot assume that an EntityID represents one institution.
#2 - WAYFless URLs
In the best practices, it is good that we have provided both options, the Identity Provider SSO and the Session Initiators. Elsevier has implemented the Identity Provider SSO piece already. They view the session initiators though as a more elegant solution. And plan to implement session initiators. This should allow for more simplified URL structure.
#3 - Shibboleth authenticated direct links to resources
Due to some funky URL structure for Science Direct, they developed shortcut urls to different parts of the site. They designed authn/access management to work on these shortcut urls. Not sure if it works in all places, but was designed to work that way. OpenURLs to ScienceDirect, when wrapped in a Shib SSO url, should also work!
There is a problem if DOI through cross ref is used. This poses a problem because it passes through cross ref. In the passing through cross ref, the authentication is lost. On the one hand Elsevier wants to promote DOI linking, on the other hand, the seamless authentication doesn't work. The workaround would have to be done at cross ref to honor the authentication assertion, but then there is also a challenge to be tackled at Elsevier end.
#4 - Shibboleth/EZproxy hybrid
From the vendor/SP perspective, it looks like just shib. Elsevier is aware of this ezproxy configuration, and has helped some institutions configure their ezproxies accordingly. There is a challenge currently with MD Consult. MD Consult is not Shibboleth enabled, yet runs on similar platform as Science Direct, so ezproxy cannot properly match and distinguish between them. So, currently, if an institution has both MD Consult and ScienceDirect, they need to use IP authn instead of Shib. Ale and Foster will pick this issue up and see what can be done to move it along.
InCommon role
There was some discussion of the role of a federation, particularly InCommon. Policy setting is important, for federation members to agree on policy. And policy takes on several forms, attributes, levels of assurance, how is security enforced, etc. From Elsevier's perspective, they provide a rather vanilla service - blanket access to members of a university. So, in terms of levels of assurance, if you are at a university, you are probably okay. Policy may be more important to other vendors.
In terms of documentation, federation should only document what is specific to the federation, and not document the technology. Refer to the technology documentation elsewhere.
What has helped European federations take off - IdP deployment had a lot of assistance from federation operators.
In Ale's opinion, greater need for federations to support federation members' deployments than to support service providers. As a service provider, Elsevier has experienced a good level of support in deployment from the federations, and from those that know the software very well. There has been some discussion about scientific publishers organizing themselves; Ale advised not to do, in his experience, once you really get going with a federation, you have gotten the hang of it and can apply to other federations.
More standardization across identity provider implementations
Would it make things easier for service providers to do so. Yes, easier for them, but doesn't mean it is best for everybody. It might be good for some federations that are centrally controlled. A large federation like InCommon might have less say over how identity providers are implemented. Need to strike a balance. The UK federation has struck a good balance.