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 _______________________________________________ Gnue-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnue-dev
