Hello, Here at Columbia, I have had success using the "common-lib-terms" approach for eduPersonEntitlement because, like you, the values available for eduPersonScopedAffiliation do not fully describe our eligible population. You can see the details here:
https://incommon.org/community/mace-registries/registrations-in-the-urnmacedirentitlement-namespace/ Another hurdle you will soon find is that vendor setups are not as flexible as they could be. As an example, a vendor will accept any number of the "eligible" values (e.g., [email protected], [email protected]) for an attribute (e.g., eduPersonScopedAffiliation), but can only use one attribute for access-control (e.g., values for eduPersonScopedAffiliation and eduPersonEntitlement cannot be combined into an OR). Seth On Thu, Mar 25, 2021 at 4:40 PM Hammer, Erich F <[email protected]> wrote: > > Tod, > > Yep, we are a member of InCommon, do have a default attribute release policy, > and do use Shibboleth for all sorts of other authentications. However, based > on many years of experience (outside the Library), I never assume anything > here is "by convention". > > For example, the IdP does release eduPersonScopedAffiliation as a default, > and that is one of the attributes JSTOR accepts. The current options > available with that attribute here are not sufficient for identifying who we > give access to eResources. I mentioned this to our IdM group and added that > JSTOR also accepts eduPersonEntitlement, and their immediate response is to > ask about the criteria for the Entitlement attribute will be used and if we > have examples of other libraries that are using it. IOW, they haven't been > asked about that attribute yet. > > I don't really have any concerns other than if our IdM group will be willing > to adjust their Shib attributes to be compatible with JSTOR (and other > vendors). I'd love to go back to the IdM group with "Yes, this is pretty > standard, and here are a few Libraries doing this". Even better would be to > add, "and here are the other large eResource vendors that use the same > attribute and who we would also like to configure for SSO". Thus, my > question. > > Thanks for the response. > > Erich > > > On Thursday, March 25, 2021 at 15:54, Tod Olson eloquently inscribed: > > > Hi Eric, > > > > I see that your institution is a member of InCommon. It is likely that your > > IdM > > group will have implemented a default attribute release policy that is based > > around InCommon conventions. JSTOR is also a member of InCommon, so > > there should be some common expectations. > > > > Use of Shibboleth has really expanded over the last N years. On our campus > > is now used heavily for all sorts of applications outside of the library: > > administrative systems, granting agencies, etc., lots of internal and > > external > > SPs. A far cry from the early-adoption days. > > > > I suggest talking to your IdM group how this transition might work, what > > concerns you might have, and whether they would share those concerns. > > > > -Tod > > > > Tod Olson <[email protected]<mailto:[email protected]>> > > Systems Librarian > > Interim Head of Integrated Library Systems > > University of Chicago Library > > > > On Mar 25, 2021, at 10:50 AM, Hammer, Erich F > > <[email protected]<mailto:[email protected]>> wrote: > > > > Hi. > > > > We are just starting to investigate moving access some of our larger > > eResource vendors away from going through EZProxy and onto > > SSO/Shibboleth. Our test case is JSTOR, and our Identity Management > > group that supports Shibboleth is asking about other libraries using the > > eduPersonEntitlement attribute. We are specifically NOT interested in > > OpenAthens. > > > > I'm also interested to know if anyone has a handle on a "standard" Shib > > attribute used by most/many of the larger vendors, or if this is going to > > be a > > rabbit hole where every vendor wants a different attribute and repeatedly > > negotiating with the IDM group for changes will put us on the "bad list". > > > > I'm open to other comments and criticisms about the whole idea too. > > > > Thanks, > > Erich > > > >
