InC-Lib-Vendor

[Mark Montague <>]

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