One of the great things about the Shibboleth inter-institution single sign-on software package is the ability for the Identity Provider to limit how much a Service Provider knows about a user’s request for service. (Not familiar with those capitalized terms? Read on for definitions.) But with this capability comes great flexibility, and with the flexibility can come lots of management overhead. So I was intrigued to see the announcement for an online webinar from the InCommon Shibboleth Federation with the title “The Challenges of User Consent” covering the issues of managing who gets access to what information about users.
From the webinar description:
Are you starting to see more requests from SPs seeking user attributes? Would you like to explore methods that would simplify the attribute release process? You aren’t alone. Campuses are seeking a scalable approach to managing attribute release that will minimize admin involvement and allow users to access sites like those that support collaborative work and want such attributes as EPPN, name, and email.
Automating the user consent procedure, combined with metadata-driven attribute release, provides an approach that greatly simplifies this process for all parties, and allows users to reach sites without delay.
Join us for a discussion and demonstration from Brown University and the University of Southern California.
Host/Moderator: Tom Barton, University of Chicago and InCommon Technical Advisory Comittee
Steven Carmody, Brown University and InCommon TAC
Russ Beall, University of Southern California>
Lots more abbreviations and technical terms there, so here is a short primer:
- Service Provider (SP)
- A web server protected by Shibboleth that a user wants to access.
- Identity Provider (IdP)
- A web server that can authenticate a user (determine who the user is, typically with username/password) and store User Attributes.
- User Attributes
- Data about a user, including name, email address, affiliation status (student, employee, faculty, etc.), eduPersonPrincipalName, and TargetedIDs.
- eduPersonPrincipalName (EPPN)
- A string in the form of user@domain that uniquely identifies the user at an Identity Provider. (InCommon technical definition)
- An opaque string stored/generated by the Identity Provider that is unique to each user and Service Provider pair. Passed as a User Attribute between the Identity Provider and the Service Provider, it can facilitate long-term user sessions at the Service Provider without revealing the identity of the user.
This is all stuff that as librarians we should be concerned about. Arguably, a Service Provider should only have enough information to satisfy the demands of a license agreement, and in most cases those demands can be satisfied with an assertion that a user is of a proper affiliation with a library (e.g. “patron” or “student” or “employee” or simply “member”). It is baked into the Shibboleth trust model that the Service Provider will honor the User Attributes presented by the Identity Provider.
What makes the announcement of this webinar interesting is that Service Providers seem to be asking for the non-opaque eduPersonPrincipalName attribute. I’ve long thought that TargetedID — an opaque/random string shared between the Identity Provider and Service Provider — is a much better answer to enabling privacy for functions like marked-item-lists, relevance ranking based on user search history, and other services that are unique to an individual. Because TargetedID doesn’t give away the person’s identity yet is guaranteed by the IdP to be unique to one person at one SP, it is ideal for situations when the SP doesn’t really need to know exactly who is making the request. (Sure, if a user coming to an SP with a TargetedID then gives the SP his/her name or e-mail address, then that person is no longer anonymous but that was a choice the user made.)
So I’m planning on tuning in next Wednesday to get caugh up on what is happening with User Attributes in Shibboleth-land. If you care about this kind of stuff, perhaps you can join me, too.