Shibboleth ARP GUI Management Tool for Campus Resources

1. Shibboleth Mockup - ARP GUI ManagementbySteven CarmodyBrown UniversityproxyWalter Hoehn

2. Agenda • Requirements from Focus Group • Scenarios • Goals - what problem are we trying to solve? • Model • Discussion

3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. GUI Mockup • Usability testing • http://www.stanford.edu/~jvine/shibboleth/#usability • Mockup • http://www.stanford.edu/~jvine/shibboleth/mockups/

14. 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).