Defining Use Cases for Federating Library Services

["T. Howell" <>]

Please respond inline in the e-mail. Denote changed or additional lines with a *.

For example –

The browser user has a variety of possible "launch points" that may take them to the external resource provider. For Shib-enabled sites, the flow will * vary, depending on the user's starting point. The List of Possible starting points includes: go directly to the site, use a campus maintained navigation

Thanks;

Thomas.

__________________________________________________________________

Model Name :

Shibbolized EZProxy

Description of the Assumed Model:

A library is running a combination of EZProxy and Shibboleth with a flow for interaction between library patron and EZproxy.

EZP has three distinct phases of processing:

1. Is the site Shib-enabled? If yes, always redirect directly to the site, bypassing the next two phases.
2. EZP triggers the locally configured authentication mechanism
1. EZP access control (based on groups, etc configured into EZP; grant/deny access)
3. The traditional proxy.

Assumption is that the local Shib IdP has optionally been configured to allow authN by both

• people managed by the campus IdM system, and
• people who only appear in the campus ILS system.

The browser user has a variety of possible "launch points" that may take them to the external resource provider. For Shib-enabled sites, the flow will vary, depending on the user's starting point. The list of possible starting points includes: go directly to the site, use a campus maintained navigation page (ex. http://dl.lib.brown.edu/eresources/index.php?task=alpha&ltr=S ); a campus maintained gateway of some sort (ex. metalib); a course home page in an LMS; a google search.

Note: The walk-in case is ignored in all of the use case models listed below because it is described in greater detail as part of an assumed model type.

---

Model Use Cases (Basic) :

1. Use Case Name :

• EZProxy Access with No Shibboleth, No physical location restrictions

    Use Case Description :

• Library website contains a directory of the various services which uses an EzProxy login link for external users which proxies the entire library site, allowing users to use resources through the proxy. This leverages the default EzProxy login.

• access to an SSO protected resource from
      -- on campus
      -- off campus (ie. from home, while travelling)

   Primary actor(s) :

• Member of the community (sometimes referred to as a Library Patron, but that term sometimes has a narrower meaning).

   User Type :

• Administrator, Editor, End User (Primary actor)

   Technology Type :

• N/A

   Vendor Type :

• N/A

   Precondition :

   Trigger :

• Patron attempts to access restricted resource

   Basic flow :

• Via web browser, patron attempts to access resource. Access to resource is granted.

2. Use Case Name:

• EZProxy Access with Shibboleth, No physical location restrictions

    Use Case Description:

• access to a resource protected by EZP (and not by Shibboleth) from
      -- on campus
      -- off campus (ie. from home, while travelling)

   Primary actor(s):

• Member of the community (sometimes referred to as a Library Patron, but that term sometimes has a narrower meaning).

   User Type:

• Administrator, Editor, End User (Primary actor)

   Technology Type:

• N/A

   Vendor Type :

• N/A

   Precondition :

   Trigger :

• Patron attempts to access restricted resource

   Basic flow :

• Via web browser, patron attempts to access proxy-protected resource. By virtue of AuthZ authentication process, access to resource is either granted or denied. Ultimately, services would be affiliated with a federation [InCommon] and we could bypass the proxy login entirely.

3. Use Case Name :

• EZProxy Access with No Shibboleth, physical location restrictions

    Use Case Description :

• access to an SSO protected resource from
      -- on campus
      -- off campus (ie. from home, while travelling)

   Primary actor(s) :

• Member of the community (sometimes referred to as a Library Patron, but that term sometimes has a narrower meaning).

   User Type :

• Administrator, Editor, End User (Primary actor)

   Technology Type :

• N/A

   Vendor Type :

• N/A

   Precondition :

   Trigger :

• Patron attempts to access restricted resource

   Basic flow :

• Via web browser, patron attempts to access proxy-protected resource. Access to resource is either granted or denied based the users IP address.

4. Use Case Name:

• EZProxy Access with Shibboleth, physical location restrictions

    Use Case Description:

• access to a resource protected by EZP (and not by Shibboleth) from
      -- on campus
      -- off campus (ie. from home, while travelling)

   Primary actor(s):

• Member of the community (sometimes referred to as a Library Patron, but that term sometimes has a narrower meaning).

   User Type:

• Administrator, Editor, End User (Primary actor)

   Technology Type:

• N/A

   Vendor Type :

• N/A

   Precondition :

   Trigger :

• Patron attempts to access restricted resource

   Basic flow :

• Via web browser, patron attempts to access proxy-protected resource. Access to resource is either granted or denied based the users IP address or by virtue of AuthZ authentication process which inspect attributes returned in AuthN assertion.