[OPEN-ILS-DEV] Remote patron authentication
gmc at equinoxinitiative.org
Wed Apr 10 17:34:17 EDT 2019
On Thu, Apr 4, 2019 at 8:10 PM Jeff Davis <jeff.davis at bc.libraries.coop>
> I'd like to draw attention to a new feature I've been working on, namely
> improved support for remote patron authentication and retrieval:
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
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
> - 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
- adding a user activity type for tracking authentication from the new
Implementation and Services Manager
Equinox Open Library Initiative
phone: 1-877-OPEN-ILS (673-6457)
email: gmc at equinoxInitiative.org
direct: +1 770-709-5581
cell: +1 404-984-4366
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Open-ils-dev