InCommon Library Services

I'm trying to write up my understanding of a model for getting 
EZProxy and Shibboleth to work together effectively. This is based on 
what I remember from Phase 1 of this effort. Unfortunately, I haven't 
been able to find any notes, and thus I'm forced to rely on memory -- 
always an iffy process. Fortunately, this group includes a couple of 
people from OCLC who are quite knowledgeable about EZProxy, and I'm 
hoping they will help move this towards "correctness".

I think of EZP as having two parts: a front-end and a proxy.

The front-end includes this sequence of steps:
	-- a way to configure whether the destination is shib-enabled 
or not. If the destination is shib-enabled, the user is forwarded 
there directly, bypassing the proxy.
	-- if the browser user is coming from an on-campus network, 
they are forwarded directly to the destination.
	-- if the browser user is coming from off-campus, they are 
redirected to the proxy.

The proxy is the easy part -- that's the actual re-writing proxy.

In addition, the front-end includes some sort of authorization 
mechanism. The site manager can define groups within EZP (can the 
groups be defined in ldap?), and can then create rules such as "only 
members of Group X can access Resource Y". I'm not sure where the 
authZ processing occurs in the sequence of front end processing.

One suggestion I've heard is that it makes sense to define a 
persistent url for a provider as pointing to the EZP front-end. This 
would insulate the url from changes if the vendor moves from 
IP-access control to Shib access control. Does this idea make sense?