Description of Proposed Flow – through sfx and EZProxy, to a Shibboleth protected resource

  1. User is working from off-campus.
  2. User accesses MedLine, does a search, finds relevant Abstracts.
  3. User clicks OPENURL button, gets redirected to SFX server at their home campus.
  4. SFX server provides user with a menu of choices for accessing the resource; user selects "view online" option. SFX server prepends EZproxy prefix, and redirects user to local EZProxy server, passing eventual target url and parameters to access a single article within that target ("the deep link") (note: this description was taken from the chicago page on the wiki – info from Tod – SFX is designed to pass article-specific information to the journal aggregator's service, but it's up to the journal aggregator to resolve the reference and complete the deep linking. When SFX first came out, many vendors didn't actually link down to the article level, but would leave the user at the issue, journal, or even top-level database. That was some years ago, deep linking straight to the article is now much more the norm.)
  5. CURRENTLY, For shibboleth-protected resources not appearing in EZproxy's configuration, EZproxy redirects the user browser directly to the resource, and the shibboleth transaction proceeds without further involvement of EZproxy.
  6. (Suggestion from Scott Cantor) EZProxy should redirect the user to a SessionInitiator at the SP along with a parameter telling it which IdP to use, and a parameter containing the deep link url. This will bypass all WAYF processing. The SP will use the Federation metadata to choose an appropriate protocol to use when comunicationg with the user's campus IdP. The SP will then redirect the browser user to their IdP for authentication, passing along the deep link as the eventual target.

If the deep link url looked like this: (yes, I know this isn't an OpenURL style url, but its what I have):

it would be transformed by EZProxy to:

  1. If the user has previously authenticated, then they are immediately redirected back to the "deep link" target. If they have not yet authenticated, then the normal authentication process proceeds, and they are then redirected back to the deep link url.

(From Chris Zagar: A release of EZproxy coming this summer adds the ability tomake this transformation.)

  1. If the resource does appear in EZproxy's configuration, then EZProxy redirects the browser to the "proxy" component of EZProxy.
  1. The proxy component of EZProxy accesses the real target url, and retrieves the desired online article.
  • No labels