InC-Lib-Vendor

[David Kennedy <>]

Mark,

Thank you for posing the question to this group.  I agree that the 
community would benefit from a "standard" or recommended solution to the 
problem, if one makes sense.

Regarding the current best practices document, it was written such that it 
is digestible and could be implemented by both vendors and universities. 
And so we have included only the common use case in this document, the use 
case that a single entitlement value per institution would enable the 
appropriate authorization to take place at the resource provider. 

I don't know if our group knows enough about your use case and how similar 
or different it is from others to endorse a particular solution as a best 
practice for the community to follow.  It makes sense to me though that we 
should work together to come up with a sensible approach to your situation 
and be able to provide guidance to the community, in the form of best 
practices, for others to follow.  I just don't know what that is yet.

My initial reaction is that the first option that you present (asserting 
entitlements) is the most flexible, sensible and appropriate approach.  It 
seems to me that this would keep in line with other valid use cases for 
which the common-lib-terms does not apply.

I will discuss with the rest of the group and get back to you.

Thank you
Dave

-----
David Kennedy
Application Developer
Perkins Library, Duke University
(919) 613-6831




From:
Mark Montague <>
To:

Cc:
shibboleth <>, "" 
<>
Date:
12/15/2009 03:24 PM
Subject:
[InC-Lib-Vendor] InC-Library Best Practices question




Dear members of the InCommon Library Collaboration Vendor Subgroup,

First, thank you for drafting the Best Practices document for library 
resource providers and libraries; we have found it very helpful.

We also have a question that we'd like your opinion on, and, if you feel 
it to be appropriate, to add to the Best Practices document:

When a single institution has multiple campuses, each with a different 
license from a single library resource provider, but where each campus 
shares a single IdP, user directory, and authentication infrastructure, 
what is the best practice for the IdP communicating a user's campus 
affiliation with the library resource provider?  Note that a single 
individual may be affiliated with multiple campuses.


We've asked this question on the  mailing 
list and included additional background information:

https://mail.internet2.edu/wws/arc/shibboleth-users/2009-11/msg00003.html


For a complete threaded list of replies, see "multi-campus IdPs / 
identifying campus/branch to an SP" at

https://mail.internet2.edu/wws/arc/shibboleth-users/2009-11/thrd1.html


The reason we're addressing this question to you is because in his first 
reply to us, Scott Cantor says:

> The "organizational ID" problem is coming up
> repeatedly in a lot of use cases, but there's no consensus.

We hope you can recommend a best practice in this area.


Options that we can easily accommodate include any of the following:

- asserting entitlements, in addition to common-lib-terms, to represent 
which campus license(s) should apply.

- providing eduPersonScopedAffiliation to indicate campus affiliation.

- providing the "locality" attribute from the eduOrg schema to indicate 
campus affiliation.

- providing a special attribute specific to the University of Michigan 
to indicate campus affiliation, e.g., "umichCampus" (although this is 
obviously a poor choice for a solution).



Options that are not good for us include:

- setting up a separate IdP for each campus (this is very expensive, and 
would also be confusing to users who were affiliated with more than one 
campus; and it does not make sense as all campuses share common 
directory and authentication infrastructures).

- providing the "ou" (organizational unit) attribute from our directory; 
our "ou"s are based on department affiliation and role, and are not, in 
general, reliable indicators of campus affiliation.  And restructuring 
all of our directory "ou"s for a resource provider is not feasible.



The library resource provider in question can only support multiple IdPs 
or the "ou" attribute at the current time.  They are very reluctant to 
change any of their code, but they say:

> we'd prefer any development work we do to be to an
> agreed standard, rather than implement anything one-off.

We're hoping that, with clarification from you, we can present the 
library resource provider with a compelling case for modifying their 
code to support one of the options in the first list, above.

Thanks in advance for any guidance or assistance you can provide.

                Mark Montague
                ITS Web/Database Team
                The University of Michigan