[OPEN-ILS-DEV] Remote patron authentication

[Jeff Davis]

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

Here at Sitka, we have more and more external services -- like
OverDrive, EZProxy, and Lynda.com -- that need to authenticate patrons
and retrieve information about their accounts.  Most of these services
support some form of HTTP-based authentication, but every service has
its own requirements and none of them support native Evergreen
authentication (the most broadly-supported method for authenticating
patrons is SIP, which is not fit for purpose).  Meanwhile, libraries
often need to restrict access to these external services based on patron
type, current status, standing penalties, and so on.

To meet these needs, I've been working on support for separate,
configurable HTTP API endpoints for remote patron auth.  Each endpoint
handles a different external service or authentication method.  You set
up the endpoints that you want in your Apache config -- for example,
EZProxy auth at /api/ezproxy, HTTP Basic auth at /api/basicauth.  Each
endpoint's configuration specifies:

   (1) a Perl module that processes incoming requests, authenticates the
       patron, and returns an appropriate response in a format that the
       external service understands; and

   (2) an authentication profile that defines the authentication rules
       for this endpoint, such as patron type and status.  Profiles are
       stored in a new config.remoteauth_profile database table.

There is a branch in the working repo that implements the above, with
support for HTTP Basic authentication (RFC 7617) as a proof-of-concept:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1817645-remoteauth-patron-api

(See docs/TechRef/remoteauth.adoc for technical details and 
configuration instructions.)

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?

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

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

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

- 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?

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

-- 
Jeff Davis
BC Libraries Cooperative