InCommon Library Services

[Renee Shuey <>]

Thanks Holly. This is a great summary of the issues. I have a conflict 
this afternoon and won't be able to make the call but will review these 
later today.

Renee

Eggleston, Holly wrote:
> Hi all -
>
> I've attached a matrix of the current pilot configurations, and a list of the 
> consolidated "open issues" mentioned in the pilot status surveys.
>
> For our meeting on Friday, I'd like to go through the "unresolved issues" 
> list below, clarify as needed, and identify campuses that would be willing to drive 
> investigation/testing on individual issues to move these towards resolution.
>
> I’d also like to volunteer to spearhead creation of a public space for 
> outreach as this is an area that is tied in closely with the presentation 
> process.
>  
>
> Pilot Configuration Matrix
> ==========================
>  - Cornell/Maryland/Penn/UW - is your EZproxy currently shib-enabled?
>  - Any changes, please let me know
>  - If anyone has a better layout and/or can figure out how to get this 
> sharable/editable on the wiki, be my guest.  ;>
>
>
> Unresolved issues for pilot / barriers to production implementation 
> ===================================================================
>
> 1. Sending opaque persistent identifiers (and other release attributes) to an 
> SP for each user that could be used by the SP to support personalization, 
> saved searches, etc. (Chicago, Penn, UCSD)
>   - Chicago/Penn State -- could you confirm that this is what you referring 
> to?
>
> 2. Allowing machines connected directly to the campus network to access a 
> provider without requiring the user to login (Penn)
>   - Is this solved by mod_auth_location for shibboleth and/or IP bypass on 
> EZProxy?
>
> 3. Allowing walk-in users to continue to use public terminals in the library 
> without requiring these users to login
>   - mod_auth_location
>
> 4. Hybrid environment requires maintaining full range of IP addresses with 
> vendor (UCSD, Maryland)
>
> 5. Integrating with existing tools (SFX) 
>  a. For shibboleth resources in general
>  b. To test a dual pilot/production scenario (UCSD)
>
> 6. Compatibility in a shared consortial environment with shared tools 
> (catalog, SFX, etc) (UCSD)
>
> 7. The hybrid configuration still requires high level of maintenance to keep 
> proxy up to date (Penn)
>
> 8. Ability to restrict resource access to a specific subset of patrons. (UCSD)
>   - Would this be solved with #1, above?
>   - What is the role of the IdP in managing this access?
>   - Can this currently be done with EZProxy?
>
>
> Additional Shibboleth functionality that would be useful 
> ========================================================
>
> 1. Ability for the user to consent to release custom attributes for a 
> specific vendor (Chicago, Maryland)
>   - is this tied to #1, above?
>
> 2. Ability for a known user or sp to force a prompt to reauthenticate/relogin 
> (particularly in allowing a user to override a “guest” login) (Maryland)
>
> 3. Common use of a push model. Perhaps the dominant form this will take in 
> the libsvcs world is end-user presenting a university affiliation with card 
> space. I wonder if ubiquitous-push will deal with situations like Google 
> Scholar from off-campus that AdamC raised. But there are many, many unknowns 
> (to me) in this general scenario.
>   - Chicago – can you explain this further?
>
> SP functionality
> ========================
>
> 1. Easy/automatic access to the shibboleth login page from public web 
> interface such as Google. (Cornell)
>   - Could this also be a vendor feature, easily providing shibboleth login 
> option from their landing page?)
>
> 2. A holy grail rewrite proxy that gives all current benefits, but doesn’t 
> require local configuration or user knowledge of the proxy-enabled URL. (UCSD)
>
>
> Benefits of Shibboleth-only
> ============================
>
> 1. More shib-enabled resources means less IP maintenance (Penn State)
>   - A good hybrid solution could do this too, but would require routing all activity (both remote and on-campus) through the proxy 
>
> 2. Having user-level identification would aide in resolving breach alerts 
> (Penn State)
>
> 3. Complete server-side authentication solves the lockdown user scenario 
> (UCSD)
>
> 4. Solves the restricting to specific user group restriction as long as could 
> control by attribute and/or specific login (for restricting against “guest” 
> walk-in users) (UCSD)
>
> 5. Permits seamless login to resources across multiple domains / outside of 
> the local domain. (Cornell)
>
>
>
> Holly Eggleston
> Assistant Department Head, Acquisitions
> UCSD Libraries
> 858.534.9668
> 858.534.1256 (fax)
>  (personal)
>  (licensing and electronic resources)
>
>
>
>