InC-Lib-Vendor

[Foster Zhang <>]

Andy.

We have 3 value of eduPersonEntitlement" released to outside.

urn:mace:dir:attribute-def:eduPersonEntitlement urn:mace:oclc.org:10032420    
   
urn:mace:dir:attribute-def:eduPersonEntitlement 
urn:mace:incommon:entitlement:common:1   
urn:mace:dir:attribute-def:eduPersonEntitlement 
urn:mace:dir:entitlement:common-lib-terms       

the first will be used by OCLC, and carry a value of OCLC account info.
The 2nd is used by Ebscohost and others when the common-lib-terms has not 
been released as the standard value.
The 3rd one should be used by broad applications.

eduPersonEntitlement value is set at the campus IT, to my experiences, any 
changes will require IT engineer's work.

Foster

-----Original Message-----
From: Andy Ingham [] 
Sent: Thursday, July 23, 2009 11:35 AM
To: inc-lib-vendor
Subject: [InC-Lib-Vendor] eduPersonEntitlement and our campus IT group (ITS)

Vendor subcommittee --

[I'll forewarn you that I'm sending this message the day before I'll be 
away from the office for almost two weeks, but wanted to get my ideas 
down and out before I forgot them all :) ]

Now that our EZProxy is Shibbolized (at least for the 85% of folks who 
authenticate with the standard campus ID), the next step is to 
Shibbolize individual resources.

It is obvious that "eduPersonEntitlement" will be VERY important to the 
success of this.

Since central IT on campus (ITS) controls the IdP which backends all 
this, I need to discuss with them the defining and populating of that 
attribute (among others potentially, but this is the single most 
important one).

So, I've been thinking a lot about the process:  how to approach the 
issue with them (and with Library staff), what timeline to expect, what 
*I* can do to grease the wheels (sell the importance), etc.

Since others on this group have covered this ground already, I thought 
I'd ask a few questions.

(1) How does "eduPersonEntitlement" get populated on YOUR campus?  Is it 
an on-the-fly assignment based on other criteria / conditions?  E.g., 
person A is tagged in the LDAP in a certain way as of the time of the 
auth request and so "eduPersonEntitlement" gets sent back with a value 
of "common-lib-terms" (which is what I understand to be the most 
generally useful value for this attribute)

(2) For the first 10 years of our proxy service, we've always checked 
our  ILS's patron database to verify "patron type" and "expiration date" 
to authorize use of the proxy.  We've had initial discussions with ITS 
about having THEM setup our patron db as an "attribute provider" such 
that the IdP can check these things as part of the process of 
authenticating users and releasing attributes back to the SP.  Does it 
make sense to "continue to" base the assignment of "common-lib-terms" to 
the "eduPersonEntitlement" attribute on THESE criteria or is now the 
time to break away from that reliance and base the assignment on 
criteria that is **in the campus LDAP**?

(3) How are you handling "walk in" users in this new architecture?  Or 
is this being deferred until a time when we are far enough along that we 
can start "dismantling" the IP-based setups?  (Until the vendor DOESN'T 
maintain a list of IP ranges for our campus, walk-in access will 
continue to just work as it does now, whether a patron goes directly to 
a resource or mediates through a library page that is a gatekeeper for 
EZproxy use.)

Thanks in advance for any and all thoughts on these questions.

Andy

Andy Ingham
Assistant Head, Library Systems
University Library
UNC-Chapel Hill
919-962-1288