Hey Dan, Forgive my ignorance on the issue, so this may be a stupid question, but what would happen to users that existed in the external auth system, and therefore passed authentication, but didn't have an actual user account in Evergreen; could this happen? If so, what would the system do?
Thanks, Joseph -- Public Key: [0xF8462E1593141C16]<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF8462E1593141C16> In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to live in a world that no longer exists. - Eric Hoffer On Wed, Jul 27, 2011 at 12:11 PM, Dan Wells <[email protected]> wrote: > 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 > >
