Dave,
All of the three values release to all providers. It would
be best to only have one value that should be urn:mace:dir:entitlement:common-lib-terms. It will be
easy to ask the early adopter to switch from urn:mace:incommon:entitlement:common:1,
and OCLC firstsearch’s practice to have specific value per customer is
bad.
Foster
From: David Kennedy
[mailto:]
Sent: Thursday, July 23, 2009 3:06 PM
To: Foster Zhang
Cc: inc-lib-vendor; Andy Ingham
Subject: RE: [InC-Lib-Vendor] eduPersonEntitlement and our campus IT
group (ITS)
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
>
