June 30, 2004 CAMP Shibboleth Implementation Workshop

Shibboleth

Mockup - ARP GUI Management

by

Steven Carmody

Brown University

proxy

Walter Hoehn

June 30, 2004 CAMP Shibboleth Implementation Workshop

Agenda

• Requirements from Focus Group• Scenarios• Goals - what problem are we trying to

solve?• Model• Discussion

June 30, 2004 CAMP Shibboleth Implementation Workshop

Requirements from Focus Group• Accommodate difference between campus

community vs library user community (III system)

• Gracefully handle changing definitions of users (can change over time and affect contracts and how they're negotiated).

• Concern about relationship between shib + provisioning

• Ability to delegate authority to manage attribute release policies for various groups.

• Managing licenses is a different role from managing Shibboleth ARPs

June 30, 2004 CAMP Shibboleth Implementation Workshop

Requirements from Focus Group• Relationship between Shibboleth and external

electronic resource management (ERM) database systems, system resource management modules (eg III, Ex Libris Metalib)

• Share Shibboleth integration specifications with vendors (III was mentioned specifically)

• GUI should support profiles that can be copied from one resource to another so they don't have to be set up individually each time.

• Standardization, global licensing requirements to simplify the management process for the vendor, and the Reference Librarian

June 30, 2004 CAMP Shibboleth Implementation Workshop

Requirements from Focus Group

• Track resource availability.

• Reflect distinction between the user management and license management parts (user management is external)

• Vendors want to implement level of service models, where releasing more information about a user provides a higher level of service.

June 30, 2004 CAMP Shibboleth Implementation Workshop

Scenarios - Simple

• A new content provider is licensed for the campus community

• A new content provider is licensed for a restricted community, such as a medical center, law school

• A new content provider is licensed for students in a particular course.

• A campus might have two different ARPs for the same service, enabling different service levels for different user communities

June 30, 2004 CAMP Shibboleth Implementation Workshop

Scenarios - Complex

• Instances of research centers affiliated with a campus where any staff member that is not on the faculty should be allowed access to resources

• Professors may teach at multiple campuses and determining their home campus for access rights should be possible

• There is some per use or per connection charge agreements ala OCLC.

June 30, 2004 CAMP Shibboleth Implementation Workshop

Goals - what problem are we trying to solve?

• Provide a tool for a small community of Sysadmins and Reference Librarians to manage Attribute Release Policies

• Maintain distinction between the user management tools and license management

• Simplify the process for creating ARPs (reduce the amount of data entry required)

• Make it very difficult to release wrong/extra attributes (try to isolate the admin from the underlying mechanics, and instead present the information "in their framework")

June 30, 2004 CAMP Shibboleth Implementation Workshop

Goals - what problem are we trying to solve?

• Allow ad-hoc sites to entered (hand entered data)

• Provide a debugging mode (ie when Jane Doe accesses target X, what should be released, and what is being released)

• We're still learning about how the more complicated agreements are structured, and exploring how to use attributes obtained from directories to represent them

June 30, 2004 CAMP Shibboleth Implementation Workshop

Goals - “out of scope”

• Providing a tool to maintain directory attributes• Access control for managing ARPs (in v1, you can create, I

can delete)• Defining the relation to an external electronic resource

management (ERM) database system, or external library system resource management module

• Shib is unrelated to tracking resource availability• Shib is unrelated to limiting the number of concurrent users

June 30, 2004 CAMP Shibboleth Implementation Workshop

Model

• No fine-grained access control on editing ARPs• People/roles create/manage ARPs; these are

considered "owners"; this is the primary organizing factor used by the GUI

• The directory can be used (in a variety of ways) to determine "membership" in various communities

June 30, 2004 CAMP Shibboleth Implementation Workshop

Model

• ARP creation driven off federation metadata (to find targets)

• Service level model• Targets provide service templates, which contain

service levels, and required attributes

June 30, 2004 CAMP Shibboleth Implementation Workshop

GUI Mockup

• Usability testing

• http://www.stanford.edu/~jvine/shibboleth/#usability

• Mockup• http://www.stanford.edu/~jvine/shibboleth/

mockups/

June 30, 2004 CAMP Shibboleth Implementation Workshop

Questions for the audience.....

• General feedback• Scope, how we've conceptualized• Specifying communities, what to release.....

– Specify that the ARP applies to a narrow group, and then release a generic attribute (campus does access control)

– Specify that the ARP applies to the entire campus community, provision the eligible community with a unique attribute value, and then release that value.

– Agree beforehand with the target, and release attribute values that define eligibility for the service (eg Dept = Med School, affiliation=faculty).