Models Used to Develop the various Technology Approaches linked above:
Models: Each model below organizes a series of use cases with commonalities in the technological implementation and has several related use cases of both the basic and advanced category. Specific vendor situations may be separately categorized as a model when approriate. Otherwise most use cases list the vendors of the software that are assumed to have an impact.
Basic Models: This type of model does not contain advanced use cases and typically can be complete with minor effort by the Library. A cookbook for how to go about implementing each of these use cases is intended to be created.
- Models for Use Cases - Template
- Internet2 Wiki - This is the simplest use case and is a useful case needed by anyone who wishes permission to edit these wiki pages.
Advanced Models: This type of model is implemented by more then one institution but includes complex variations on a basic use case. Cookbooks may be developed for some of these use cases and then used as a starting point to extrapolate to other similarly complex use cases.
- Models for Use Cases - Template
- Shibbolized EZproxy
- Anonymous personalization
- Walk In
- EZProxy via LMS - Accessing resources when the point of origination is within a Learning Management Systen (LMS)
Vendor Specific Models:
(The following use cases will be edited and moved into the list of above based on the Models for Use Cases Template.)
- Anonymous personalization (Old)
- Direct to Vendor
- Seamless ILLiad
- ER Librarian Workflow
- ER Librarian Workflow v2
- Ares
- On phone or In person user verification
- User goes to external service (abstracts), does a search, finds a useful openlink hit, goes back to campus, goes directly to the referenced article. Do this from home to a Shibb enabled resource.
- Institution hosts an IdP in addition to the Primary Institutions IdP
- User not in primary authentication source
- PDS Ex Libris PDS (patron directory service) module for support of many of their products.
- Circe Dynex: Shibb enabling java app.
- Shibb enable staff user access in addition to patron users
- Instructor wants to add a deeplink to a course in an LMS system and we want the link to work no matter where the user happens to be. The link has to be durable from year to year.
- Blackboard
- An instructor chooses a list of books in the OPAC and then wants them to be automatically pushed into the eShelf of students so that they can view them while inside the LMS.
- Federated Search which returns results that a user is allowed to view.
- Federated Search which returns results that are based on facets related to a group (or other shibb attribute)
- Two seperate federations accessing the same SP
- Two seperate shibb enabled IDs, ie. I have campus credentials and I also have an account with the ALA or ACM
- How to link two identies?
Category 3: Singular Cases
This type of use case is generally so specialized that it is only implemented by a single institution.
- Singular Use Case Template
- Replacing existing Java applications which store user password tables in the clear (either DB or in file on the file system)
Use cases useful notes and links:
User Types (User Profiles) -
- Admin
- LDAP defined
- Local file defined
Attribute Sets (there are four general sets that we have identified)-
- Single attribute - the user is identified by the IdP as an authenticated member of the institution
- Minimum recommended - the user is identified by the IdP as an authenticated member of the institution plus several commonly used attributes are transmitted to the SP.
- Optional attributes - these are those additional attributes that extend the minimum recommended set for added usability
- Recommended "do not use" list of attributes - these are those attributes which can be provided but aren't in a best practices environment [for example users social security number (ssn)]
License issues -
- It is suggested that institutions work together as a group with vendors to attempt to modify language in contracts which supports the outdated IP authentication model and supports a move towards user defined group models.
Abstracted Library Authentication and Authorization Models -
- We have mediating authentication/authorization application
- We have individual staff/back office access versus individual user/client/patron access
- Differentiated experiences for two groups of users because their grouping information/attributes have been exposed.
- Non-differentiated experiences for two groups because their grouping information/attributes have been hidden.
Questions:
- primary and tertiary sets of attributes, uApprove (developed by the Swiss federation), how does a users know which sites should be properly accessable to their Shibb account?, how does a user know the state of their various cookies as associated with their ID?