[OPEN-ILS-DEV] Remote patron authentication

[Jeff Davis]

Thanks very much for the feedback, Galen (and thanks to the person who 
replied off-list).  Detailed responses are below.


On 2019-04-10 2:34 p.m., Galen Charlton wrote:
> 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.

There are definitely cases where some patron info needs to be 
retrievable.  I had anticipated managing this via templates; doing it 
with profile attributes is a bit more complicated but I see how it can 
be done.  Anyway, I strongly agree that we should minimize the amount of 
personal information that is returned.


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

"Don't allow Overdrive auth on my account" makes sense to the patron, 
but gets tricky if multiple vendors are using the same HTTP basic auth 
endpoint or something like that.  I suppose we could add a nullable 
opt_out_usr_setting field to config.remoteauth_profile and let libraries 
sort out something that works for their implementation.


> Two changes I would suggest are:
> 
> - tossing together an Angular admin interface for managing 
> config.remoteauth_profile

I was leaving this for last, but I'll put something together. :)


> - adding a user activity type for tracking authentication from the new 
> interface

Right now all requests are using the "remoteauth" activity type.  On 
reflection, you ought to be able to specify the activity type in the 
authentication profile, so I'll do that.

Thanks again!

Jeff