InC-Lib-Vendor

[David Kennedy <>]

> 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.
> 


I approached our OIT identity management group a few
months back and started a discussion about this.  Told them about
our group, and some of the problems we are trying to solve (mentioned the
moving away from IP management and moving towards personalized services)
and that we are trying to create some standardization across library vendors.
 I did not have a good pitch for why this was important to them, and
so I really was letting them know what I was doing, and that I might be
asking for their support as I went along.  Fortunately for me, they
have already bought into Shib a while ago, and saw this as moving Shib
forward, and so have been very supportive of this project.

It happens also that there are some specific projects,
such as alumni access to databases and Duke Net ID for life, that tie in
really well with the Shibboleth and EZproxy work.  So, supporting
me has helped the discussion for both of those projects.

At around the same time, I also approached the library
staff that currently manage our vendor contracts and IP addresses, and
coordinate with our library IT office for EZproxy administration.  I
basically gave them a slightly different pitch, but the same importance
(away from IP and towards seamless personalized services).  I also
coupled the discussion with them another idea I had to create a web interface
for them to manage ezproxy themselves and become the functional owners
of the app, giving them better access to the process.  Eased them
into the idea that I was going to be asking for their assistance in accessing
vendor administrative interfaces. 



> 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)
> 

Still working on this at Duke, although the holdup
has been the library and not OIT.  We just decided today, that eduPersonEntitlement
will be based on eduPersonPrimaryAffiliation and will include Faculty,
Staff, Student, and Affiliate.  OIT can't currently differentiate
Affiliate types, so we need to include them all.

OIT gave us the option of manually maintaining a list
of Affiliates with Grouper to be included in the entitlement, but it did
not seem feasible

> (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**?
> 

My personal opinion is that there should be a shift
for libraries to get out of the business of identity management, that this
should be a campus function whenever possible.  So, I would push to
base the assignment on criteria that is in the campus LDAP.  That
is easy to say for me because I don't have to maintain the campus ldap.
 But I have found, both at MD and Duke, that campus directory administrators
actually want data centralized in their directory.

But, then again, both MD and Duke's library patron
databases were fed by the directory and the directories in both cases have
been capable of representing the patron types at least in generic terms,
such as eduPersonAffiliation.

Your model is very plausible though.  And it
is appealing because the library then has the control over the level of
specificity that you want in order to determine eligibility for inclusion
in contracts.  This is something that we considered while I was at
MD, although our OIT was not receptive to it, so I would be interested
to see how this model works.

> (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.)
> 

I am deferring on handling "walk in" users
via Shibboleth.  Their access will still be maintained via IP, and
will continue to work for us in the same way that you note.