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 <[email protected]>:
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 [email protected]
Hekman Library at Calvin College
616.526.7133
