Defining Use Cases for Federating Library Services

["Dale,Andy" <>]

Based on my discussion with Steve, I drew up this flow diagram. As you
can see I only included the sequence diagram for the Primary Flow... let
me know what you think.

Some thoughts about the OpenURL case:

As I understand OpenURL - I can go to an indexing service and assuming
that they recognize my institutional affiliation (via IP Auth?) they
will put MY institutions link resolver into their search results along
with the 'standard' bibliographic meta-data about the resources I find:
So, if I click on a result I will be sent to my link resolver who will
work out where an instance of the resource that I actually have access
to can be found.  

If that is the case then it seems to me that the primary flow is
different when a resource is accessed via OpenURL the difference being
driven by the fact that IF the user is off-campus (our main case) but
the indexing service affiliated them; they probably accessed the
indexing service via EZProxy... Therefore when the link resolver
redirects to the resource; an active EZProxy session can be assumed. 

I would not be at all surprised that both my understanding of OpenURL
and my further assumptions are wrong. Once I have clarity I will attempt
some diagrams for this use case.

(when is our next call?)
Andy


-----Original Message-----
From:  [] 
Sent: Tuesday, November 03, 2009 8:15 AM
To: Dale,Andy
Subject: RE: [InC-Lib-UseCase] flow diagram, simple EZP use case

I had a discussion with the Shib core team about the flow during the 
EZProxy-IDP-Resource steps... the answer turns out to be simpler than 
I expected...

I had thought that the approach might vary depending on which 
protocol was being used, or other factors.... fortunately, I was 
wrong.... we can suggest a single approach that will work for all 
versions of Shibboleth and all versions of the protocols.

It goes like this.....

1) EZP should redirect the browser user to the resource, passing 
along the identifier for the campus:

http://pqshibboleth.proquest.com/Login? 
providerId=CAMPUS_ID&target=deep link url to end up at

2) The SP/resource redirects the browser user back to their campus 
IDP; the user authenticates if necessary.

3) The IDP redirects the browser user back to the resource; the SHib 
SP code validates the received assertions.

4) The Shib SP code redirects the user to the deep link.

Attachment: Basic EZProxy Access Flow.png
Description: Basic EZProxy Access Flow.png

Attachment: IPAuth Access via EXProxy and Shib.png
Description: IPAuth Access via EXProxy and Shib.png