Disruptive Library Technology Jester » Shibboleth

“The Challenges of User Consent” — Handling Shibboleth User Attributes

Peter Murray — Fri, 06 May 2011 20:51:38 +0000

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
Presenters:
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)
TargetedID: 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.

Microsoft Giving Away Developer Software to Students

Peter Murray — Wed, 20 Feb 2008 14:20:53 +0000

Stu Hicks, one of OhioLINK’s systems engineers, told the OhioLINK staff last night about a new program at Microsoft called DreamSpark. Through this program, post-secondary students around the world who are attending accredited schools or universities can download some of Microsoft’s big developer and designer tools free of charge. At the time and place this post is being written, the list of software is:

Visual Studio 2008 Professional Edition
Windows Server 2003 Standard Edition
SQL Server 2005 Developers Edition
Expression Studio
XNA Game Studio
Visual Studio 2005 Professional Edition
Visual C# 2005 Express Edition
Visual C++ 2005 Express Edition
Visual Basic 2005 Express Edition
SQL Server 2005 Express Edition
Visual Web Developer 2005 Express Edition
Visual J# 2005 Express Edition
Virtual PC 2007

Eligibility is determined by either a Shibboleth or a Windows CardSpace identity provider on the student’s campus. One must link a Windows Live ID account with that campus identity provider and renew that eligibility about once every 12 months. They are using Shibboleth for what it was designed for; it is actually nice to see Microsoft recognize that only a true/false response from the campus is required to determine eligibility and that no personally-identifying attributes are passed from the campus to the Microsoft server to make this happen. There are FAQs for students and for higher education administrators.

The blog post announcing the program has an video interview with Bill Gates, but unfortunately one needs Microsoft’s Flash alternative called Silverlight to watch it.

Access Management and Provisioning Technology

Peter Murray — Tue, 18 Jul 2006 19:21:41 +0000

Building on the shoulders of others — isn’t that how that quote goes? There has been a stack of printouts on my desk for a while now for various access management and service provisioning technologies. Rather than keep the paper, I’m putting the list here so I know how to get back to them if/when I need to. (Of course, along the way if you’d like to comment on them or suggest others to look at, please feel free to do so in the comments.) Note, too, that by listing them here I’m not proposing, or even sure if, all of these pieces come together to a coherent structure.

Grouper — Internet2 Middleware

“Grouper is an open source toolkit for managing groups. It is designed to function as the core element of a common infrastructure for managing group information across integrated applications and repositories. Grouper combines multiple sources of group information, both automated and manual, in managing memberships and other group information in a Group Registry, a central information asset complementary to a site’s Person Registry. Grouper manages two primary types of objects: groups and namespaces. Groups are created and named within a namespace. Group management authority can be limited ”

Now at version 0.9, Grouper is part of a suite of tools from the NSF Middleware Initiative (NMI) that supports “development, testing, and dissemination of architectures, software, and practices in the areas of identity and access management.”

Signet – Internet2 Middleware

“Core middleware services such as identity management, directory, and authentication provide a foundation for secure, manageable applications throughout an institution. Even with this foundation, as systems and applications proliferate it becomes more and more difficult to manage user access consistently and cost-effectively. [The Signet] privilege management service is a relatively new component of campus middleware that addresses this problem by providing centralized management of user privileges across a range of applications. The benefits of this service include: a standard user interface for privilege administrators; consistent, simplified policy definition, via roles and integration with core campus organizational data; improved visibility, understandability, and auditability of privilege information; and standard interfaces to other infrastructure services and to application systems to support integration.”

Now at version 1.01, released 29-Mar-2006. Could this kind of provisioning service be used to generate XACML files to drive FEDORA?

OASIS eXtensible Access Control Markup Language (XACML)

“XACML is expected to address fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, authorization based on classes of activities, and content introspection (i.e. authorization based on both the requestor and potentially attribute values within the target where the values of the attributes may not be known to the policy writer). XACML is also expected to suggest a policy authorization model to guide implementers of the authorization mechanism.”

Sun’s XACML Implementation (available at Sourceforge) is the access management engine embedded into the FEDORA repository.

Acegi Security System for Spring

“Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.”

Release 1.0.0 came out in May 2006 after nearly two years of development.

Authentication and Access in a Metasearch Environment

Peter Murray — Sat, 24 Jun 2006 01:23:57 +0000

Mike Teets of OCLC and I teamed up to write an article on Metasearch Authentication and Access Management for this month’s D-Lib Magazine. The first part of the article is a bit of a primer on access management techniques followed by a survey and analysis of access management schemes in use last year. The key part, I think, is the “Recommendations” (access restrictions by IP address plus authenticated proxy servers is the best one can hope for right now) and “Next Steps” (Shibboleth is superior to other access control mechanisms beyond IP/proxy that one might consider, but there is lots of work to be done).

The last paragraph of the article sets out the questions:

In the space between “good enough” (the status quo) and “ideal” (Shibboleth federations) lie many questions for our community. For libraries there are questions like “Are IP address access management and proxy servers sufficient to meet your current and future needs?” and “How much more are you willing to spend on an implementation of a Shibboleth environment?” For content providers: “Are you satisfied with IP address access management and proxy servers for protecting your intellectual property?” and “Can you implement Shibboleth as a common access management system for interaction with metasearch engines (and possibly end-user access)?” And for metasearch service providers: “What kinds of requirements are you willing satisfy?” and “What are you willing to charge?” The NISO Metasearch Initiative Task Group on Access Management encourages the broad community to discuss these questions. NISO is committed to working with the Shibboleth developers to develop practical solutions to the issues raised.

So there are the questions, as best Mike and I can describe. What do you think?

OhioLINK is seeking to fill a Systems Engineer position. Interested?

Peter Murray — Fri, 23 Jun 2006 23:15:44 +0000

OhioLINK is seeking candidates to fill a newly-created position: Systems Engineer – Access Manager. This position will work with other OhioLINK staff in providing support of daily operations and will serve a primary role as Access Manager. As Access Manager, this position will support users who are experiencing access issues to OhioLINK’s databases and services including IP management, remote authentication, Shibboleth implementation, and analyzing networking issues.

Qualified candidates will have a Bachelor’s of Science or Arts in computer science or a related technical field, OR a minimum of three years equivalent experience in computer operations. Knowledge of UNIX/Linux systems, networking infrastructure, backup and security strategies, performance monitoring and tuning is required. Understanding of and experience with LDAP, e-mail, Apache, mSQL, Sun Java Enterprise System, Shibboleth, Perl, Shell Scripting, C/C++ programming is highly desirable. Good communications skills are expected.

Please send a resume and a list of three references to resume@ohiolink.edu. Or you can mail a copy to Resume, 2455 North Star Road, Suite 300, Columbus, OH, 43221. Review of candidates will begin July 3, 2006, and will continue until the position is filled. Minimum salary for this position is $48,000.

The text was modified to remove a link to resume@ohiolink.edu.