1. June 30, 2004CAMP Shibboleth Implementation Workshop Shibboleth Mockup - ARP GUI Management by Steven Carmody Brown University proxy Walter Hoehn

2. June 30, 2004CAMP Shibboleth Implementation Workshop Agenda Requirements from Focus Group Scenarios Goals - what problem are we trying to solve? Model Discussion

3. June 30, 2004CAMP 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

4. June 30, 2004CAMP 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

5. June 30, 2004CAMP 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.

6. June 30, 2004CAMP 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

7. June 30, 2004CAMP 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.

8. June 30, 2004CAMP 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")

9. June 30, 2004CAMP 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

10. June 30, 2004CAMP 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

11. June 30, 2004CAMP 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

12. June 30, 2004CAMP 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

13. June 30, 2004CAMP Shibboleth Implementation Workshop GUI Mockup Usability testing http://www.stanford.edu/~jvine/shibboleth/#usabil ity Mockup http://www.stanford.edu/~jvine/shibboleth/mocku ps/

14. June 30, 2004CAMP 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).