[OPEN-ILS-DEV] Extending Authentication

[Thomas Berezansky]

I think that there should be an auth context involved in the calls,  
similar to how we have the login type now (though currently it is sent  
as part of the args to, I believe, the "here is the password" response  
after initializing the login attempt).

Authenticators could use that to make decisions, or an authenticator  
could be flagged as being just for certain types of logins for  
automatic choice. I think that would make it easier to keep things  
from colliding between the OPAC and Staff Client.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Dan Wells <dbw2 at calvin.edu>:

> Hello all,
>
> This email is meant to get the ball rolling again concerning  
> alternate authentication schemes for Evergreen.  What follows is  
> some rough ideas (most borrowed from the original thread and other  
> software), not a complete plan, so all input is highly encouraged.   
> The original thread was pretty fractured, but you can read it here:
>
> http://list.georgialibraries.org/pipermail/open-ils-dev/2009-December/005481.html
>
> The first big decision is this: does the client need to learn new  
> authentication techniques, or do all negotiations happen via a  
> proxy?  Despite our current authentication protocol being partially  
> handled client-side, I think, ultimately, authentication via proxy  
> will cover the vast majority of cases in a much more doable way.   
> The current native authentication has an advantage of being usable  
> over insecure connections, but I cannot see that working out for  
> many other protocols, if any, so is it worth the trouble?
>
> Also, for the initial implementation, I think we should limit our  
> design to single-factor authentication (that is, just username and  
> password).  Again, this a trade-off for covering the vast majority  
> of needs without overdesigning.
>
> So, I believe step one should be to create an 'open-ils.auth_proxy'  
> server to mediate all authentication requests (code which does this  
> for the native auth already exists in WWW/Proxy.pm, but it is  
> unclear to me whether it can or should be leveraged directly).  It  
> would have an 'authenticate' method which expects at least two  
> parameters, 'username' and 'password', and an optional third  
> parameter, called perhaps 'authenticator', which would supply the  
> 'name' of a defined authenticator (in the auth_proxy config).  This  
> server would also have an 'authenticators' method which would return  
> to the client a list of available authenticators, including labels  
> for display.
>
> One possible layout for defining the available authenticators might be:
>
> <authenticators>
> 	<authenticator>
> 		<name>calvin_college_ldap</name>
> 		<label>College Login</label>
> 		<target>open-ils.ldap_auth</target>
> 		<ldap_server>udirectory.calvin.edu</ldap_server>
> 		<some_other_param>my_param_value</some_other_param>
> 		...
> 	</authenticator>
> 	<authenticator>
> 		<name>calvin_seminary_ldap</name>
> 		<label>Seminary Login</label>
> 		<target>open-ils.ldap_auth</target>
> 		<ldap_server>udirectory.calvinseminary.edu</ldap_server>
> 		...
> 	</authenticator>
> 	<authenticator>
> 		<name>native</name>
> 		<label>Evergreen Login</label>
> 	</authenticator>
> </authenticators>
>
> Each entry would have, at minimum, a 'name' and a 'label', and  
> anything other than the 'native' would also need a 'target' (the  
> server which the request would be passed off to).  It would also  
> contain any other configuration information which is specific to  
> that authenticator.  We can use this configuration area to:
>   - define the available entry points, including any data the  
> service needs to authenticate other than the username and password
>   - define which authenticators are tried (and the order they are  
> tried in) in the absence of a choice from the client
>
> I am specifically using the term 'authenticator' rather than  
> 'protocol' to better clarify the fact that you may define more than  
> one 'authenticator' which use the same underlying protocol.
>
> With this setup, the client's job is very easy.  At a mininum, send  
> your username and password to 'open-ils.auth_proxy.authenticate',  
> then wait for a token or a denial.  The client could also first  
> query the '.authenticators' method and allow the user to choose  
> which service to use.  The authenticator servers would be expected  
> to supply their own 'validate' method which would take as arguments  
> 'username', 'password', and an array of options, and return (at  
> minimum) a 'pass' or 'fail' code.  If the credentials 'pass', it is  
> then up to auth_proxy (perhaps via a new exposed method in  
> open-ils.auth) to generate and return the token needed.
>
> Thoughts?
>
> Thanks,
> Dan
>
>
> --
> *********************************************************************************
> Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
> Hekman Library at Calvin College
> 616.526.7133
>
>