Hi, On Thu, Apr 4, 2019 at 8:10 PM Jeff Davis <jeff.da...@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: g...@equinoxinitiative.org web: https://equinoxInitiative.org direct: +1 770-709-5581 cell: +1 404-984-4366