The session will provide an overview of the NSDL access management system, and provide guidance on how to approach integrating the system into services developed by projects. Some of the highlights and problems that groups have already faced with integrating will be shared with participants.

Notes - Registration and User Profiles

18 attendees.

Shibboleth Access Management System

Why the web needs identity? Web originally designed for open access to text documents. HTTP developed as a stateless technology. Since then, web has become more sophisticated with ideas for customization and personalization. Also, knowledge of who you are working with, and reputation management.

Challenges include privacy (who gets to see or use information about them). Ending up with lots of passwords on separate accounts all over the place. Service developers have to build user profile management systems. Limitations of protocols such as HTTP that dont have authentication.

Shibboleth Overview. Based on federated identity management thats between the many accounts model versus a single Passport-style mechanism. Access control can be name based, group based, role based, etc. User privacy is central to the design of shibboleth. A user controls how much of their information, or profile, is released to a service. Shibboleth is standards based, using SAML 1.1 (security access markup language based on XML). Shibboleth architecture splits the world into two parts; origins (identity providers) and targets (resource providers). Origins manage actual user profiles. Targets manage access. Shibboleth doesnt manage how authentication at the origin, thats up to how the origin deals with this e.g. Kerberos-based system, LDAP based system etc. The origin links with the local registration system. The login link on the NSDL.org homepage links to a shibboleth enabled system. NSDL.org manages its own user area (registering with NSDL), or you can use an account on another shibboleth origin that NSDL knows about.

The documentation has improved, but there is still some work to be done.

The presentation showed a few use cases, or scenarios. Some identified how services could use profile information to adjust the service, e.g. accessibility for hearing or sight impaired information available from the profile. Another identified how flexible subscription arrangements could be organized.

The new challenge is how to deal with the middle school focus i.e. where is the origin node for the students.

Resource shibboleth.internet2.edu.

Questions.

Who in NSDL is using this? Old Dominion and the Physics archive are piloting use.

Who are the competitors? Is there another choice that we should look at? Liberty Alliance is another major similar mechanism from some 25 commercial vendors (e.g. sun) who dont want to base on something like Passport. Liberty is also working with SAML. Shibboleth focuses on federation (useful for educational networks) whereas Liberty is more bi-lateral. There is hope for compatibility with the future SAML 2.0 development.

http://www.projectliberty.org/

What happens if I have different origin accounts? Simple answer, you can log in to the one that gives the best access. But in a network, you could envision aggregation of profiles from different origins.

Is NSDL going to run this indefinitely? Its one of the current core mechanisms that will be kept going, but its a limited implementation. Weld like to see more origins in the community.

What about confidentiality? For example, students putting flames, or in-appropriate use of the site. You could, currently, get back to the insititution the user came from and complain. But shibboleth could disguise this? The target can be set such that some part of the user attributes are sent to the target which could be used if needed. An extension of this is the idea of reputation management. Shibboleth has a lot of flexibility in what information is made available between an origin and a target. There is also the use of the persistent identifier which is unique to the target resource.

There were a number of questions related to the specifics of setting up the policies with respect to profile attributes being viewable.

Whats the scalabilty of this? If the performance is 1 second turn around for the current implementations, what happens when you scale 100, or 1000 magnitude more users? Weve tested for hundreds of transactions at once (not sessions) which would be OK for a scale of a university.

How do we work with the new middle-school focus? Consider SIFF schools interoperability framework. But who holds the actual data? In the K12 realm theres a lot of student administration systems and thats held at that district level. But this data is all over the map, issues of quality, what IT resources do the schools have? There were a number of questions around the issues of how to authenticate students/teachers. There was a consensus this is going to be a big problem.

Issue of NSDL evaluation and assessment excersizes? What about working with institutional IRBs? Issues of dealing with IRB responsibilities in an institution particularly around the persistent ID. This has specific issues with respect to some of the NSDL evaluation and assessment efforts where you may want to identify a user across a number of services to help track their use of the NSDL.

Some discussion of what happens to the large public base that dont have registration at an insititution with an origin node. NSDL.org is one possible mechanism to allow them to have an account, but may not deal with the authentication issue, i.e., this is really a 5th grade teacher.

A number of the questions came from the audience trying to see how this may work with their library, service, or collection. It may be useful to have a broad set of example use cases for people to review.

Comments

Please enter any comments in the following format.

(commenters' initials) - month/day [comment date]
comment

NSDL thanks DLESE for hosting the swikis for the NSDL Annual Meeting 2003.

Swiki Features