gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUe-dev] Some thoughts about authentication in gnue-common ...


From: Johannes Vetter
Subject: [GNUe-dev] Some thoughts about authentication in gnue-common ...
Date: Tue, 19 Jul 2005 16:35:03 +0200

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

-- 
BYTEWISE Software GmbH               Tel +43 (5577) 89877-0
i.A. Johannes Vetter                 Fax +43 (5577) 89877-66
A-6890 Lustenau, Enga 2              http://www.bytewise.at
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wir bieten Installation und Support für Ubuntu: ein auf
GNU/Linux basierendes Softwaresystem für Arbeitsplatzrechner

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]