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./
