InC-Lib-Vendor

[Andy Ingham <>]

A thorny issue, indeed.

I would strongly second the notion that the negotiations be centered 
around the IdP releasing certain agreed-upon (standard) attributes about 
the user (e.g., nursing undergrad, to use Dave's example) RATHER than 
centered around setting entitlements at the IdP based upon a given set 
of criteria specific to the negotiations.

Not only does it strike me as the "appropriate" way, I am FAR more 
confident, on a pragmatic level, of my ability to convince the identity 
management staff here at UNC to release those sorts of attributes than 
to implement the processes to create, manage, and release entitlements 
that have very specific use and therefore limited value (in the larger 
context of the University).

I want to be very judicious with my requests and expectations for the 
campus's ID management staff, as they are very busy folks managing 
identities for tens of thousands of users for scores of applications.

Having said all this, I am not at all sure to what degree we presently 
HAVE attributes for things as specific as "nursing undergrad" set in the 
campus LDAP.  To me, though, that simply means we need to expect heading 
in that getting the "right" environment set up will take time and 
inclusive communications.  (Note to self:  try to find out WHO on my 
campus is even involved with negotiating contracts with resource vendors 
in the hopes that shifting technological requirements can be included in 
those negotiations ...)

Andy

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


David Kennedy wrote:
> Don,
>
> It has been a busy week for me so far, sorry for the delay in response. 
>  I have been remiss in thanking you for the engaging conversation last 
> week.  Thank you.
>
> I have put notes from our conversation up on the group's wiki: 
> https://spaces.internet2.edu/display/inclibrary/Minutes+from+Vendor+subgroup+call+10-9-09 
>
>
> Thank you for the update and especially in incorporating the best 
> practices into your future plans.
>
> Regarding the business problem that you note below and that we have 
> talked about, we did discuss in our call that the best practices 
> discussion regarding attribute usage was based on contracts defined for 
> common library terms.  And that the best practices gives us all an 
> opportunity to possibly rethink how we are doing things.  Although the 
> use case that you describe with Ohio State doesn't fit within the 
> assumed common library terms, I would like to indulge in some more 
> conversation, because this is certainly an interesting challenge.
>
> Although not a unique challenge, I think it is one that is shared 
> probably in particular by a lot of journals in fields of medicine or 
> law.  I wonder how these challenges are dealt with at the institutional 
> level as much as at the vendor level.  In your experience, have the 
> universities that you have set up multiple authos for been able to 
> distinguish the groups at their university?  And how (what methods) do 
> the users of these separate groups authenticate to your services?
>
> In thinking this through with Shib, I look at eduPerson, and wonder if 
> any combination of the standard attribute set can be used to define 
> these subsets of campus populations.  In some cases, probably yes, but 
> in others, probably no.
>
> I am not sure that I am getting to a point, except that Shibboleth, the 
> technology, seems to be a good fit for passing user attributes to a 
> service and allowing the service to make the authorization decision. 
>  Which is what we are talking about here, attribute-based authorization. 
>  With Shibboleth though, do you anticipate that an institution's IdP 
> administrator will be able to assign different entitlements to different 
> subsets of the campus population that correspond to their access to your 
> resources?  Or would it be appropriate for the identity provider to 
> provide attributes about the individual and the service to perform the 
> authorization logic based on the user's attributes?  
>
> An example of this might be a resource that is restricted to nursing 
> students.  Ideally, I think the identity provider in a Shib scenario 
> would be presenting information about the user, such as the user's field 
> of study (nursing) and institutional affiliation (undergrad), without 
> needing to understand too much about the service that it is providing 
> the information to.  And then the service provider would be configured 
> with the logic that determines what resources a user is granted access 
> to based on their supplied attributes.  
>
> Conceptually, I personally think this is a better model than asking the 
> identity provider to determine, based on its own internal logic, the 
> authorizations (or entitlements) for a particular resource or set of 
> resources with a service provider that a user should be granted.
>
> In taking this simple example and applying it to OCLC IDM structure, 
> could you conceive of allowing identity providers to release to you 
> arbitrary (well hopefully standard) sets of user attributes, and allow 
> for configurations or mappings of those attributes to authos for cases 
> that do not fit within the common library terms agreements?  I may be 
> oversimplifying the complexities, and this has already been thought 
> through to a different conclusion.  What do you think?
>
> Dave
>
> -----
> David Kennedy
> Application Developer
> Perkins Library, Duke University
> (919) 613-6831
>
>
>
> From:   "Hamparian,Don" <>
> To: 	"David Kennedy" <>, "Zavar,Jason" 
> <>, "Dale,Andy" <>
> Cc:     <>
> Date:   10/12/2009 10:32 AM
> Subject: 	[InC-Lib-Vendor] RE: InCommon Library Services / OCLC - 
> conference call - 10/9 1PM ET
>
>
> ------------------------------------------------------------------------
>
>
>
> Hello all, it was a good, engaging conversation. I think where we left 
> it was how we can resolve the business problem of resolving fine grained 
> rights access to institution’s content:
>  
> Institution x has three ‘rights profiles’ for access to content owned or 
> hosted at OCLC.  Institution is defined as the Law Library Ohio State 
> University, for example.  There is an OCLC ‘symbol’ for this library. 
>  There are three content ‘rights profiles’ or ‘authos’ for this 
> institutions: law students, law school alumni, and undergrad students. 
>  Assuming a IdP at the university level, not at the law school level, 
> how do we represent this via incoming attributes?
>  
> Regarding the best practices document, we have placed the WAYFless URL 
> support on the new content platform, and authenticated links to 
> resources on the new content platform on our enhancement list. No 
> guarantees yet but these look like good enhancements from my standpoint.
>  
> I believe ‘authorization via eduPerson attributes’ is desirable but we 
> don’t have solution to the above stated business problem yet.
>  
> Don
>  
> *From:* David Kennedy [] *
> Sent:* Thursday, October 08, 2009 10:06 AM*
> To:* Hamparian,Don; Zavar,Jason; Dale,Andy*
> Cc:* *
> Subject:* InCommon Library Services / OCLC - conference call - 10/9 1PM ET
>  
> Don,
>
> I have below a draft agenda for our conversation tomorrow.  Let me know 
> if there are any changes you would like.  
>
> Notice that I have some pre-reading listed.  It would be helpful if you 
> have a chance to look at these documents.  Also, here is a link to our 
> wiki so that you know who we are: _
> __https://spaces.internet2.edu/display/inclibrary/Vendor+Subgroup_
>
> Dave
>
> Call Details:
> Friday, October 9, 2009 - 1PM EDT
> 866-411-0013 (US & Canada)
> 734-615-7474 (non-US/Canada)
> Access code: 0122004#
>
> AGENDA
>
> Pre-reading: _
> __https://spaces.internet2.edu/display/inclibrary/Best+Practices_ _
> __https://spaces.internet2.edu/display/inclibrary/RegistryOfResources_
>
> Introductions
>  - including brief overview of InCommon Library Services Collaboration
>
> OCLC - overview of Shibboleth implementation
>  - usage of Shibboleth SP software (SessionInitiators?)
>  - implementation of WAYFless URLs and direct links to resources
>  - what has or hasn't worked
>  - future plans
>
> Implementation-specific questions/comments
>  - When using ezproxy, library can construct a link to go directly to 
> the database to start a search; the url looks like: _
> __http://firstsearch.oclc.org/dbname=AGRICOLA_
> When using oclc shib wayfless url, the dbname attribute is not 
> available, so the default db on first search is always defaulting to 
> worldcat
>  - eduPersonEntitlement - OCLC requires customer specific string to be 
> coded in edupersonentitlement.  This implementation does not use the 
> 'standard' value of common-lib-terms.  Also, for some IdP 
> implementations, this value is also shared with other service providers. 
>  Can this be changed to use 'common-lib-terms'?
>
> Topics for discussion:
>
> Best Practices
>  - are these feasible for resource providers
>  - do these make sense
>  - thoughts on how to go about making this best practice amongst 
> resource providers
>
> What role should InCommon or the InCommon Library Services Collaboration 
> play?
>  - policy setters
>  - documenters
>  - testers
>  - implementation documentation/assistance
>
> Is there a desire/need for standardization across federation members' 
> identity provider implementations that would simplify the process for 
> resource providers' configurations?
>
> What are we missing, especially things that you have learned from 
> dealing with other federations besides InCommon?
>
>
>
> -----
> David Kennedy
> Application Developer
> Perkins Library, Duke University
> (919) 613-6831