Re: Some thoughts about authentication in gnue-common ...

Johannes, 

You are pretty much describing the mechanism currently in place:

  http://www.gnuenterprise.org/tools/common/docs/technotes/00005.txt

However, I would love to see some classes pre-made authenticators included in 
the GCommon tree as you describe, such as "PAM", "LDAP", "Database Table", 
etc. 

-- Jason 



On Tuesday 19 July 2005 9:35 am, Johannes Vetter wrote:
> Hi,
>
> Currently we do have only authentication services provided by the
> backends in use, i.e. username and password are authenticated by the
> database server. This proposal should point out a way of having more
> options on authentication:
>
>
> Where to define which authentication to use
> -------------------------------------------
>
> Every connection in the connections.conf might have an authentication
> option of the following format:
>
> authentication=auth-agent:auth-param;auth-param;...
>
> Where 'auth-agent' is the name of the authentication agent to use and
> 'auth-param' are optional parameters needed by the auth-agent.
>
>
> Who's starting authentication
> -----------------------------
>
> In general authentication is started by a GConnection instance when the
> connection is asked to login (like it is now). If the connection has no
> auth-agent assigned, everything will be as it is now. This means the
> GConnection instance will call 'getLoginFields' and pass them to the
> GLoginHandler assigned to the connection.
>
> If an auth-agent is defined, it's authenticate () method will be called,
> with a default-dictionary as parameter. Such defaults might come either
> from a .netrc-file or from the connections.conf entry itself. Now there
> are three situations which might occur:
>
> a) the auth-agent returns 'None'. This means authentication is
> successfully finished.
> b) the auth-agent returns a structure similair to 'getLoginFields ()'.
> This structur will be passed to the GLoginHandler assigned to the
> connection for further processing (= user input)
> c) an exception is raised, which means authentication failed.
>
> In case of b) the result will be a dictionary of key/value pairs holding
> the data given by the user. Now this dictionary will be given as
> parameter to another call of 'authenticate ()'. So another
> authentication cycle starts. As a result, one of the above situations
> can occur. Note: the result-dictionaries will be merged together and
> passed in to all following authenticate () calls.
>
> If authentication was successfull, the authenticator's 'credentials'
> dictionary will be used as 'loginData' (this usually contains keys like
> 'username', 'password', ...). This dictionary will now be used for the
> connect-method of the GConnection instance. Using such a credentials
> dictionary allows an auth-agent to provide different values for backend
> login than used for authenticating access to the service itself.
>
>
> Note: we cannot use something like 'getLoginFields' for an auth-agent
> since not all authenticators can determine the number of questions or
> information they will ask for, e.g. using PAM one could have
> pam_permit.so and another one could have pam_unix.so or pam_ssh.so. All
> modules will ask different questions (where the first one would even ask
> nothing).
>
>
> Interface of GAuthenticator
> ---------------------------
>
> Methods:
>
> __init__ (parameters, kwargs):
>   Create a new instance using the given parameter dictionary (as
> retrieved from connections.conf)
>
> authenticate (answerDictionary):
>   Start or proceed (using answerDictionary) with authentication. Either
> return None (authentication finished successfully), or return a
> structure as returned by GConnection.getLoginFields (). If
> authentication failed, raise an apropriate exception.
>
> Attributes:
>
> parameters : dictionary with parameters for the auth-agent (as retrieved
> from connections.conf)
> credentials: dictionary with all credentials passed to
> GConnection.connect () after successfull authentication. This dictionary
> must be populated by the authenticate () method.
>
>
> Note: the parameters can be given as a dictionary or as a string of the
> form name=value;name=value;name=...  In the latter case it will be
> converted into a parameter dictionary with 'name' as keys and 'value' as
> values. If the constructor has keyword arguments they will be added to
> the parameter dictionary as well. Parameters given as keyword arguments
> have highest priority. Following are some samples:
>
>       GAuthenticator ({'foo': 'bar', 'bar': 'baz'})
>       GAuthenticator ('foo=bar;bar=baz', foobar=10)
>       GAuthenticator (host = "my.ldap-server.net")
>       ...
>
>
>
> Which credentials should be used for backend-(database-) login?
> ---------------------------------------------------------------
>
> With an auth-agent we might not have all information needed for a
> database-login. An auth-agent might check a private key asking for a
> passphrase only. Maybe there's no username available through
> authentication, but the backend database must have a username and a
> password. So we need a concept of providing username and password (or
> database-credentials in general) in a secure manner, after being
> successfully authenticated. This mechanism is connected to a
> GConnection, since every connection will need it's own set of
> credentials. Should we add a third class 'GCredentials' to the
> GConnections.loginToConnection (), which provides diffrent mechanisms of
> obtaining such information (like reading from .netrc, user-read-only
> files, database-supplied, from GLoginHandler, connections.conf, ...)
>
> What do you think about this ... ?
>
> Thanks,
>
> Johannes