I've now updated the wiki page at https://wiki.evergreen-ils.org/doku.php?id=dev%3Aproposal%3Aopenathens_integration to reflect the discussion we've had - settings will now be library-specific under local administration.
We're aiming to complete the development work next week, so this is your last chance for any other feedback on the feature. Regards Julian ───── Julian Clementson Full stack software engineer On 12/09/2019, 20:56, "Open-ils-dev on behalf of Václav Jansa" <[email protected] on behalf of [email protected]> wrote: Hi Julian, thanks for complete explanation. Now, I understand, that Evergreen will be able to server for OpenAthens as authority/authenticity resource, complete out of SAML world. I dreamed a bit and hope for full SAML (IdP,SP) implementation. Almost all big libraries in Czech republic are Shibbolethized, so NCIP and SAML are from my view two last missing pieces needed for competition with closed source ILS (for example Aleph). Many thanks Vaclav Jansa (just a IT part of our family EG consortium ;-) ) On 12. 09. 19 20:00, Julian Clementson wrote: > Hi Linda, > > Thanks for your question. I think the answer is no, but it depends exactly what you mean! SAML and Shibboleth can be used in different ways, so let me go through what this proposal would support, and what it would not support. > > Anyone looking for a quick answer might want to go straight to the diagrams at the end of this email. > > The aim of this feature is to give libraries that are OpenAthens customers a way to connect their patrons to online resources that are using OpenAthens login. This is done by making a connection from Evergreen to OpenAthens, in such a way that patrons are logged in to OpenAthens on the basis of their Evergreen login. Once patrons have access to OpenAthens they will be able to access online resources that are connected to OpenAthens. OpenAthens is fully compatible with SAML on the resource publisher side, so it doesn't matter what software the resource publisher is using. They could be using Shibboleth SP, or any other SAML access control software, or any other protocol supported by OpenAthens such as OpenID Connect. I don't think that was your question, but I wanted to make sure! > > As for how Evergreen will sign patrons in to OpenAthens, it's true that OpenAthens also supports using SAML for that purpose. So if you already have a login system running Shibboleth IdP, or any other SAML-based login system, you can connect that into OpenAthens. But we're not proposing to implement SAML within Evergreen. Implementing SAML is quite complex, and there aren't any ready-made Perl libraries that would help us do so. (There is one Perl library for SAML, but it only supports using SAML to log in to a Perl application, not the other way round.) Because of the complexities of SAML, OpenAthens provides its own simpler API for logging users in, which can be used instead, and that's what we're proposing to implement in Evergreen. > > Because we're not implementing SAML, this feature won't allow you to connect Evergreen directly to SAML resources without going via OpenAthens. In other words, this feature will only be of use to libraries that are OpenAthens customers. > > It's also worth making clear that this feature is not about using other systems to log in to Evergreen, whether via SAML or any other protocol. So it won't support using Shibboleth IdP for example as a way of logging in to Evergreen. This feature is only about using Evergreen to log in to another system (in this case OpenAthens), not the other way around. > > There's one other specific case worth mentioning, that I mentioned in my earlier reply to Jeff, which is using OpenAthens itself to log in to Evergreen. That would allow a library that is an OpenAthens customer to set up their Evergreen instance as an online resource that could be accessed by patrons of other libraries in their consortium, who are using a different log in system from Evergreen - using OpenAthens as the intermediary link. That's also not included in this proposal. OpenAthens would support doing this using SAML, or more simply using OpenID Connect, so maybe that's a separate feature proposal that could be logged for Evergreen. I'm happy to help define it further if the community is interested in it. > > To put it in a diagrammatic form that I hope will work in plain text: > > - Supported: > Evergreen --> OpenAthens --> Resource (Shibboleth SP etc) > > - Not supported: > Evergreen --X--> Resource (Shibboleth SP etc) > > - Not supported: > Shibboleth IdP --X--> Evergreen > > - Not supported: > Any user directory --> OpenAthens --X--> Evergreen > > I've probably answered many more questions than you asked, but maybe this helps others on the list better understand the scope of this feature, and prompts more questions or suggestions. > > Let me know if you have any more questions or concerns about the feature. > > Julian > > ───── > Julian Clementson > Full stack software engineer > > > On 12/09/2019, 10:19, "Linda Jansova" <[email protected]> wrote: > > Hi Julian, > > Your proposed feature looks great! Do you plan that this implementation > of SAML will be fully configurable for both OpenAthens and Shibboleth > (or any other SAML compatible system)? > > Looking at > https://openathens.org/openathens-shibboleth-shibboleth-openathens/ it > seems that it might be possible... > > Thank you for your answer in advance! > > Linda > > On 9/10/19 10:15 AM, Julian Clementson wrote: > > Thanks Chris, then that’s what we’ll do. Thank you. > > > > I’ll update this list again when I’ve updated the wiki page and again > > when the implementation is ready for code review. I’ll start a separate > > thread if we need any help understanding how to build Library Settings > > under the hood! > > > > Regards, > > > > Julian > > > > ───── > > > > *Julian Clementson*** > > > > Full stack software engineer > > > > *From: *Open-ils-dev <[email protected]> on > > behalf of Chris Sharp <[email protected]> > > *Reply to: *Evergreen Development Discussion List > > <[email protected]> > > *Date: *Monday, 9 September 2019 at 18:06 > > *To: *Evergreen Development Discussion List > > <[email protected]> > > *Subject: *Re: [OPEN-ILS-DEV] Feature Proposal - OpenAthens integration > > > > Julian, > > > > We've discussed this on the PINES end of things, and we agree with > > Jeff's approach to use the Library Settings infrastructure if it's > > feasible on your end. This question occurred to me (the use of a global > > flag) when you demo-ed the prototype for our staff, but I didn't bring > > it up because, as you mentioned, ours is a limited use case, but if it's > > doable, making the feature more usable for other Evergreen instances > > would be beneficial all around. It's also in line with how other third > > parties have written add-ons/crosswalks for Evergreen in the past. > > > > Please let us know if you need any further confirmation from the PINES end. > > > > Thanks to both you and Jeff for having this open discussion! > > > > Chris > > > > On Fri, Sep 6, 2019 at 11:51 AM Julian Clementson > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Jeff, > > > > Thanks for that helpful explanation. I've had a look round Local > > Administration and seen how settings have an organisational unit > > scope, which we would need for this as well. So long as Evergreen is > > flexible enough to add new settings that work in the same way, then > > it should keep everyone happy. So then I think the aim then would be > > for OpenAthens settings to be its own page under Local Administration. > > > > I'm hoping we get some detailed feedback from someone who is closer > > to PINES as well, then we can confirm this is valid. I'll start > > drafting the second option in more detail on the wiki page anyway > > and let everyone know when it's ready to re-review. > > > > Thanks, > > Julian > > > > ───── > > Julian Clementson > > Full stack software engineer > > > > > > On 05/09/2019, 22:03, "Open-ils-dev on behalf of Jeff Davis" > > <[email protected] > > <mailto:[email protected]> on behalf of > > [email protected] <mailto:[email protected]>> > > wrote: > > > > Hi Julian, > > > > Thanks for the detailed response. If auth models where > > Evergreen is not > > the ID provider are simply out of scope, fair enough. :) > > > > As for supporting multiple OpenAthens domains per Evergreen > > instance, > > Evergreen has fairly robust support for assigning different > > settings to > > different libraries within the same consortium. Based on a naive > > reading of your proof-of-concept, it would be pretty > > straightforward to > > change your global flags to library settings. For example, in > > EGCatLoader.pm, instead of this: > > > > my $openathens_config = $ctx->{openathens_config}; > > > > you could do something like this: > > > > my $openathens_config = $ctx->{get_org_setting}->( > > $org_unit, 'openathens_config'); > > > > which would grab the appropriate value for the "openathens_config" > > setting from the actor.org_unit_setting database table instead of > > config.global_flag. Lookups in EGCatLoader/OpenAthens.pm would > > work the > > same way, you'd just need to define your context library before > > looking > > up any settings using something like this: > > > > my $org_unit = $ctx->{physical_loc} || $ctx->{aou_tree}->()->id; > > > > If I understand correctly, this would allow a single Evergreen > > instance > > to support multiple OpenAthens domains without having to do any > > partitioning in OpenAthens. It would also support cases where > > not all > > of the libraries in a consortium are OpenAthens customers (my > > consortium > > has over 70 libraries and only one uses OpenAthens; I'd like to > > use > > OpenAthens login at that one library and native Evergreen login > > at all > > the others). It's only a suggestion, but I think this approach > > would > > address the PINES use case equally well while also making the > > current > > development more useful to future potential customers. > > > > Jeff > > > > > > On 2019-09-05 1:29 a.m., Julian Clementson wrote: > > > Hi Jeff, > > > > > > You're right to point out that this feature has a limited > > scope. I've only been looking at the public library case, where > > Evergreen is the identity provider. That's the current feature that > > we at OpenAthens have been asked to contribute to Evergreen for the > > benefit of Georgia Public Libraries and any other public library > > consortia that are also OpenAthens customers. > > > > > > For the type of post-secondary case you describe, OpenAthens > > can already be configured to authenticate against other identify > > providers, such as Active Directory. What's missing is being able to > > configure Evergreen to authenticate against either Active Directory > > locally, or against OpenAthens, which in turn authenticates against > > whichever identity provider is configured for a particular library. > > I think adding new ways of authenticating into Evergreen should be > > treated as separate features. They are quite different from this > > feature, which is about using Evergreen to authenticate into another > > system. That's not to say the OpenAthens team would never contribute > > a separate feature for authenticating into Evergreen using > > OpenAthens, or provide help to someone else who wants to take it on > > - just to make clear that it's not in scope for the current round of > > work that's been triggered by the GALILEO single sign-on project. > > > > > > Going back to the feature for using Evergreen to authenticate > > into OpenAthens, and to answer your second question, a single > > OpenAthens domain per Evergreen instance is certainly simpler to > > implement, and is the solution preferred by OpenAthens. If the > > consortium needs partitioning between libraries within OpenAthens, > > we propose that the top-level administrator for the consortium would > > create sub-organisations within the OpenAthens domain, one for each > > library, and set up mapping rules to map users into different > > sub-organisations depending on their home library setting. Each > > sub-organisation would have an associated administrator account that > > the branch librarian could use to view their local users and > > resource usage stats. The ability to set up these sub-organisations > > and mapping rules already exists in OpenAthens. Whereas if we were > > to implement multiple OpenAthens domains per Evergreen instance, we > > would have to develop a similar mapping feature within the Evergreen > > code. It's not impossible but is duplicating a feature we already > > have in OpenAthens. But if anyone thinks that the proposed way of > > doing things would be a show-stopper for the PINES consortium > > implementation, then we'll have to re-think! > > > > > > Regards, > > > Julian > > > > > > ───── > > > Julian Clementson > > > Full stack software engineer > > > > > > > > > On 03/09/2019, 18:48, "Open-ils-dev on behalf of Jeff Davis" > > <[email protected] > > <mailto:[email protected]> on behalf of > > [email protected] <mailto:[email protected]>> > > wrote: > > > > > > Hi there, > > > > > > It's exciting to hear that OpenAthens integration is in > > the works! We > > > have several libraries that will be very interested. > > Thanks also for > > > the detailed proposal and documentation. > > > > > > I have a couple of questions. The proposal seems to > > assume that > > > Evergreen will be the authoritative identity provider, > > but I think that > > > often won't be the case for OpenAthens customers. > > Suppose I'm at a > > > post-secondary institution that uses a centralized > > Active Directory > > > service for single sign-on. I want students to use > > their SSO > > > credentials to be able to login to library resources > > including online > > > databases and the Evergreen OPAC, so ideally OpenAthens > > would > > > authenticate against my institution's Active Directory, > > not against > > > Evergreen. The development proposal says that > > resource-initiated login > > > must be delegated to Evergreen, which sounds like users > > would be > > > authenticated against EG instead of Active Directory. Am I > > > understanding correctly? > > > > > > The proposal also says that only a single OpenAthens > > domain is allowed > > > for an entire Evergreen consortium. Are there technical > > limitations > > > that make this necessary? There will be cases where > > multiple libraries > > > sharing the same Evergreen instance will want to have > > their own > > > independent OpenAthens setup, but it sounds like the > > proposal precludes > > > that. > > > > > > Thanks again! I'm looking forward to seeing where this > > goes. > > > > > > Jeff Davis > > > BC Libraries Cooperative > > > > > > > > > On 2019-09-02 3:06 a.m., Julian Clementson wrote: > > > > Hello everyone, > > > > > > > > I'd like to introduce a new feature proposal and ask > > for your feedback. > > > > > > > > Launchpad link - > > https://bugs.launchpad.net/evergreen/+bug/1842297 > > > > > > > > The feature will provide integration between Evergreen > > and OpenAthens, a > > > > global cloud-based single sign-on service. > > > > > > > > The background is that the GALILEO Consortium of > > libraries in Georgia > > > > has selected OpenAthens to deliver a state-wide > > solution for single > > > > sign-on, and this contract includes integrating > > Evergreen into > > > > OpenAthens, so that PINES patrons can seamlessly access > > > > OpenAthens-authenticated resources. > > > > > > > > The OpenAthens development team has been contracted to > > implement the > > > > integration on behalf of GPLS, and I've been assigned > > as the lead > > > > developer for the project. I demonstrated a proof of > > concept to selected > > > > representatives of the Evergreen community and the > > PINES consortium back > > > > in July. The aim is to get this feature accepted into > > an upcoming > > > > release so that it is ready for PINES to start using > > towards the end of > > > > the year. > > > > > > > > I have now documented the feature in detail on > > DocuWiki - see > > > > > > https://wiki.evergreen-ils.org/doku.php?id=dev%3Aproposal%3Aopenathens_integration > > > > > > > > I have also published the proposed code changes and > > documentation, > > > > subject to community review of course - see > > > > > > https://github.com/openathens/Evergreen/commit/ed85f8f82795e4439315e897438d75e99e0e7cde > > > > > > > > I welcome feedback and discussion, so as to improve > > the feature > > > > description and get the code into a state where the > > community is happy > > > > to accept it. > > > > > > > > Thank you and kind regards, > > > > > > > > Julian > > > > > > > > ───── > > > > > > > > *Julian Clementson* > > > > > > > > Full stack software engineer > > > > > > > > *T* > > > > > > > > > > > > > > > > +44 (0)20 3998 9178 > > > > > > > > *W* > > > > > > > > > > > > > > > > openathens.org <http://openathens.org> > > <https://openathens.org/> > > > > > > > > Open Athens > > > > > > > > ──────────── > > > > > > > > OpenAthens is a Jisc enterprise. Jisc is a registered > > charity (number > > > > 1149740) and a company limited by guarantee which is > > registered in > > > > England under Company No. 5747339, VAT No. GB 197 0632 > > 86. Jisc's > > > > registered office is: One Castlepark, Tower Hill, > > Bristol, BS2 0JA. T > > > > 0203 697 5800. > > > > > > > > > > > > > > > > > > > > > -- > > > > Image removed by sender. > > > > > > > > *Chris Sharp, PINES System Administrator* > > > > ------------------------------------------------------------------------ > > > > *Georgia Public Library Service * > > > > 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341 > > > > (404) 235-7147| [email protected] > > <mailto:[email protected]> > > > > Image removed by sender. > > <https://www.facebook.com/georgialibraries>Image removed by sender. > > <https://www.twitter.com/georgialibs> > > > > /Join our email list/ <http://georgialibraries.org/subscription/>///for > > stories of Georgia libraries making an impact in our communities./ > > > > >
