[OPEN-ILS-DEV] Extending Authentication

[Joseph Lewis]

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 <dbw2 at calvin.edu> 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 dbw2 at calvin.edu
> Hekman Library at Calvin College
> 616.526.7133
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110727/6dec69cd/attachment.htm>