[OPEN-ILS-DEV] Remote patron authentication

[Galen Charlton]

Hi,

On Thu, Apr 4, 2019 at 8:10 PM Jeff Davis <jeff.davis at bc.libraries.coop>
wrote:
>
> I'd like to draw attention to a new feature I've been working on, namely
> improved support for remote patron authentication and retrieval:
>
> https://bugs.launchpad.net/evergreen/+bug/1817645

Thank you, this looks like it will be very useful.

> It should be easy enough to add support for other services and
> authentication methods, like EZProxy, PatronAPI, or even NCIP Lookup
> User requests.  It could also be extended to support more sophisticated
> auth schemes.  Ideally, the most common vendors and services would be
> supported out of the box.  Before I proceed, though, I'd appreciate any
> feedback from the community on the code, the design, or the basic
> approach.  In particular, I have the following questions:
>
> - I used mod_perl to avoid introducing new dependencies.  Is it the
>    right tool?

I think it is for now. Of course, a patron authentication gateway doesn't
need to be a full-blown mod_perl application, and I could envision an
approach that used a lighter-weight PSGI server, but that discussion is
likely best deferred until (and if) we start thinking about moving away
from mod_perl entirely.

> - Currently, all auth endpoints use OpenILS::WWW::RemoteAuth as the
>    mod_perl handler.  Would it make more sense for each authentication
>    type to use a different handler?  Using the same handler simplifies
>    some configuration and hopefully allows Apache processes to be reused
>    by different endpoints, but maybe distinct handlers are preferable.

I'm in favor of a unified approach that shares as much configuration as
possible. In particular, I think that might encourage tightly controlling
the patron attributes that are allowed to be returned for any given
authentication type.

I applaud the fact that by returning only the identifier,
OpenILS::WWW::RemoteAuth::Basic currently is effectively just returning a
Boolean yes/no about whether the patron is authorized to use the resource.
While I suspect we'll not be able to insist that a Boolean authorization
decision is the /only/ response that all authentication clients will get
(and LIKE IT! ;) ), centralizing retrieval of patron data in
OpenILS::WWW::RemoteAuth and adding attributes to config.remoteauth_profile
to control what patron fields are given to a handler may help to keep a lid
on data exposure.

> - Will the current design handle a high volume of patron auth requests?

I would think so, at least as much as any other non-TPAC mod_perl handler.
In the worst case, if the startup cost of forking Apache backends and
initializing TPAC gets to be too much for a given site, the authentication
handlers could be moved to a separate Apache instance similar to the old
apache2-websockets instances.

> - Are there any reasonable use cases that can't be accommodated by the
>    current design?  So far, authentication profiles can restrict auth
>    based on home library, usergroup (by requiring a perm that is only
>    granted to certain usergroups), blocks/standing penalties, and
>    active/expired status.

The only addition that immediately comes to mind might be adding a user
setting that allows a patron to opt out of allowing their account to be
used for remote authentication of anything else.

> - To make live tests work, an endpoint for Basic HTTP authentication
>    will be made available at /api/basicauth by default, restricted to
>    local access only.  Is that OK (and if not, how do we do live tests)?
>    Do we want to use a different URL path?

I think that's OK as is.

> - Is there a better way to manage the disparate authentication
>    requirements of library vendors?

I think simply having a HTTP basic authentication handler would be huge as
a first step.

Two changes I would suggest are:

- tossing together an Angular admin interface for managing
config.remoteauth_profile
- adding a user activity type for tracking authentication from the new
interface

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  gmc at equinoxInitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20190410/45f24d73/attachment.html>