[OPEN-ILS-DEV] Extending Authentication

[Dan Wells]

Hello Joseph,

That is certainly a related issue but is not directly covered by this proposal.  Initially I would expect this case to simply return a 'user not found' type error.  The authentication system will only answer the question "Is this person who they say they are?".  How the user account gets into the system (whether periodically or 'on-the-fly') will need to covered separately.

Dan

>>> On 7/27/2011 at 2:20 PM, Joseph Lewis <joehms22 at gmail.com> wrote:
> 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=0xF846 
> 2E1593141C16>
> 
> 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
>>
>>