Defining Use Cases for Federating Library Services

["Paul B. Hill" <>]

Hi,

I was looking at https://spaces.internet2.edu/display/inclibrary/Shibbolized+EZproxy once again, and feeling like many of the use cases that have been discussed on the various call have not yet been captured in the wiki. I felt like the template was not helping me organize my thoughts. Instead I started typing up some notes in an outline and came up with the following:

EZProxy use cases:

 

1. No authentication required to campus EZProxy. IP address access control restricted to the campus.
1. Campus runs no VPN or proxies - all connections really should be local to the campus
2. Campus runs a VPN or some other form of proxy which lets external users appear as if they are on campus

2. Authentication is required to the campus EZProxy to access SOME of the resources mediated via EZProxy. IP address access control is not an issue for the resources requiring authentication to the EZProxy system. Note that "SOME" in this case means anywhere from 1 of N, through N of N.
1. Campus may be assuming that a successful authentication justifies authorization. (Formal use case should include explanatory text on why this is not a good thing.)
   
2. Campus may be requiring addition introspection of institutional data to determine if the user is authorized to access the resource.  The particulars of the authorization decision process MAY be affected if Shibboleth is used as the authentication mechanism.

3. If the resource being mediated supports Shibboleth directly, then EZProxy MAY be configured to redirect the user directly to the external SP, requiring the user to authenticate to the external system, via Shibboleth.
4. BLC case - the "federation" does not use Shibboleth, nor are all of its members a member of a single Shibboleth federation. It uses a hierarchy of EZProxy servers to weave the trust fabric between the federation members.
1. Some members use Shibboleth as the local authentication mechanism to the local EZProxy server which is the gateway into the EZProxy federation.
2. Some members MAY use IP address access control as the mechanism to control access to the local campus EZProxy
3. Some members MAY use other authentication mechanisms to authenticate to the local campus EZProxy.

5. People that are off the campus network MAY attempt to access a resource without contacting the campus EZProxy.
1. Shibboleth authentication to the campus IDP via InCommon
1. Correct attributes might not be released and access will be denied.
2. SP may grant access, but how do we ensure that the authorization process matched the intended authorization process as implemented on the campus EZProxy?
2. Are there cases where Shibboleth access is enabled for some federations, but not InCommon?

6. Granularity cases:
1. A subset of the campus should be granted access to a subset of the resources
1. Factors affecting authorization may include: eduPersonAffiliation, school/department/organizational unit,
2. How are exceptions to the normal policy granted? E.g. someone appears as an "affiliate" but they are actually an instructor for a particular course this semester.

7. Multiple campus IdPs.
1. Some campuses or university systems will have multiple IdPs. EZProxy must be able to handle scoped identifiers in order to properly distinguish users and facilitate proper access control decisions to be made.
1. The multiple IdPs will be members of a campus or university specific federation.
2. Is there ever a case where someone would want an EZProxy server to accept authentications from a more general federation such as InCommon?
1. Yes, if a campus is a content creator and has decided to use a local EZProxy server to mediate access to the content. They may decide to use Shibboleth authentication to the EZProxy service for all members of an interorganizational federation.

Are there other major buckets that I have missed? Would anyone care to volunteer to grab one of the numbered cases and rework it into the formal template?

Paul