Background
Business Operations Use Cases
Academic and Research Use Cases
Residential Life Use Cases
Main Library Use Cases
Branch Library Use Cases
Guests and Non-Traditional Affiliates Use Cases
Background
A question that we need to ask ourselves is why do we need to document various technology approaches and their associated use cases? The answer is simple, we need to create an understanding of the benefits of using Shibboleth to solve issues of managing resource access. Several other specific reasons that we have identified are: use cases are meant to help make a policy decision to shibboleth enable a resource, use cases also assist in trying to promote this technology to the administration, third it helps people formulate internal policy, and finally use cases are less focused on a specific technology and more focus on the user of the library and how they utilize the library to meet their needs.
We also wish to generate documentation to support cookbook solutions to many of the use cases below. Also as a result of clarifying use cases we hope to attract additional shibboleth enabled (and to-be-shibboleth-enabled) vendors to InCommon and thereby to the member institutions of InCommon. We need to identify additional local applications directly supported by libraries and/or other large intra-university divisions who support various library functions.
A large portion of the use cases touch on various aspects that will require Shibboleth enabling the proxy system. We need to investigate the "friends of the library" & POI groups (as well as others as of yet unidentified groups) into the Shibbolized access to resources (for libraries currently, these groups are only stored in the library ILS system). Eventually we need to reconcile campus federations and the InCommon federation.
Another big issue to investigate are Federated Service Providers. At present there are approximately 100 information providers in the U.K. federation; the U.S. lags in getting vendors into InCommon. At Brown, for example, the librarians believe that getting the 15-20 most-used external resources Shib-enabled would take 90-95 percent of the traffic off the proxy server. On customer surveys, users complain more about the proxy than everything else combined.
Also, regarding ARPs and Privacy Tags, due to the laborious requirements of releasing information fields that are stored in LDAP it would behoove us to look at ways to determine how to handle having users make decisions about which attributes third-party providers will receive. Brown is most of the way through a deployment of uApprove, which allows users to see which attributes are about to be released and to approve/disapprove. These processes will require education of the users as to the process, but also that disapproval will prevent access.
The first product of the following uses cases should be a "Getting Started Guide" which helps to outline what steps a user should take to resolve the issues explored here. Keep in mind that though a lot of these use cases relate specifically to libraries, it is possible to extrapolate to other portions of a university or institution that have similar needs.
Business Operations Use Cases
Like any large organization, libraries must manage employees and finances, purchase equipment and services, and maintain records for their own internal and for external (or regulatory) purposes. A host of access management use cases arise in our business unit, many of which share strong similarities to equivalent use cases in the private sector, but some of which may differ as a result of qualitative differences in the way our institutions conceptualize institutional business processes. Here are some representative use cases that evolve from the business operations environment (note this description was borrowed from the Camp wiki documentation):
- Budget Access by Director and Assistant (Example) - Sarah is the new Director of Facilities Management. As the Director, she has the authority within the institutional ERP system to manage the access rights afforded to other individuals with respect to fund codes within Facilities Management. The Director wishes to have her administrative assistant process monthly budget reconciliation statements for her non-salary fund codes, but wishes to manage her salary fund codes directly. She explicitly grants her administrative assistant access to read and reconcile transactions against her non-salary fund codes in the ERP, but leaves herself as the sole individual with access to her salary fund codes. (Single authority identified by organizational hierarchy grants by fiat to single subject multiple privileges on a single target resource constrained by resource scoping)