InC-Lib-Vendor

[David Kennedy <>]

Foster,

Are these three values of eduPersonEntitlement
released to all InCommon service providers, or are they released individually
to the appropriate service provider?

BTW, I started a thread on the shib-users
list this morning about this attribute and how it is not currently standardized,
which I think has resulted in the three different values that you are currently
releasing.

Dave

-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831


Foster Zhang <> wrote on 07/23/2009
02:45:36 PM:

> 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 [mailto:] 
> 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
>