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
