1 / 14

Shibboleth Mockup - ARP GUI Management by Steven Carmody Brown University proxy Walter Hoehn

Shibboleth Mockup - ARP GUI Management by Steven Carmody Brown University proxy Walter Hoehn. Agenda. Requirements from Focus Group Scenarios Goals - what problem are we trying to solve? Model Discussion. Requirements from Focus Group.

chaela
Télécharger la présentation

Shibboleth Mockup - ARP GUI Management by Steven Carmody Brown University proxy Walter Hoehn

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

More Related