InCommon Library Services

so, pushing bravely forward, I'd like to see if we can agree on the 
processing sequence in EZP. I expect this will lead to some 
suggestions of modifications tot hat flow, and possibly some 
additional exits to local routines.....

there is also the point that some vendors have pushed the 
responsibility for authZ processing back to the campuses, and that 
some of this has been incorporated into EZP . I certainly understand 
why this happened -- in the days when IP-based access control was the 
only option for the vendor, and the campus wanted to license Resource 
X for a subset of the community, then the campus had to do the authZ. 
But, technology moves forward, and perhaps we can push this 
responsibility back to the vendors....

here's my current guess at the EZP logic sequence:

1) is it possible to wrap Shib around EZP, so that the user has to 
login to Shib before anything else occurs? Does this make sense?

2) if the destination/resource is shib-enabled, send the user 
directly to the resource and skip the rest of the processing. This is 
often considered a plus, because traffic is needlessly sent thru the 
proxy (for scaling reasons, and for "proxy issue" reasons.

3) if the user is coming from a specified set of IP address ranges, 
send the user directly to the resource

4) EZP authentication step. Can be done by EZP, or user can be 
redirected to local authN system. Cookies are probably generated at 
this step, to create the impression of SSO.

5) EZP authZ step. Apparently, without Shib this requires maintaining 
within EZP static lists of all authorized people. With Shib, David 
Kennedy has described this sequence:

At 5:06 PM -0400 4/2/09, David Kennedy wrote:
> EZproxy, as a Shibboleth service provider, can consume user 
> attributes that are supplied by the identity provider.  And it can 
> use those user attributes to assign users (or user sessions) to 
> ezproxy "Groups".  
>
> EZproxy database configurations can also be assigned to groups.
>
> Therefore, a particular user may have access through ezproxy to some 
> databases and not others.

Q -- presumably this means that a site would NOT do step 2 above ?

6) at this stage, EZP decide to send the user directly to the site or 
via the proxy ?

Issues:

-- guests -- library walkins are a known issue. Phase 1 developed 
some approaches for them. Are there other types of "guests" (who 
require no login).

-- when EZP is being used to automate logins to vendors who are using 
a single userid/pass to sign in to their site.

-- relationship of EZP to "normal WAYF process".