On Wed, 11 Nov 1998, Elliot Lee wrote:

> Perhaps if the auth database were abstracted enough to allow writing a PAM
> module for it, then the auth server could use the auth database API
> directly for decryption purposes, and then the actual "are they allowed to
> connect" check goes through PAM, which might then call the pam_codadb
> module as well as any other pam modules...

I may have fired off my previous email a little rapidly; indeed PAM does
not fit into the authentication case, but I think (as text below
documents) that PAM can fit into the authorization step as you allude to
above.

--

Right now the authorization/authentication functions of the auth server
are seperated as follows:

The authentication stage happens at RPC bind time -- that is, you can't
bind without authenticating.  This implemented by the auth server level
code passing a function pointer to a GetKeys function that allows the RPC
code to ask GetKeys for a session and handshake key (password) for an
identity binary blob passed in.  Our GetKeys actually performs a switch
based on an AuthenticationType field to determine who to pass the key
retrieval request off to -- the base case is against a local password
database (Where the passwords, as mentioned, are essentially in
cleartext).  With the Kerberos patches applied, the identity may
optionally be an authenticator, which the kerberos code will then use to
generate the handshake key (i.e., the session key stored in the
authenticator).  This stage is presumably the stage that PAM cannot be
used with.

The authorization stage is for the retrieval of tokens from the auth
server.  That is, using the secure RPC binding now available as a result
of authentication, an RPC call 'GetTokens' may be made.  The auth server
then returns tokens to the user.  The GetTokens call may presumably be
forced to fail in bad cases.  The vice id (at this point determined) is
tied to the connection internally in the auth server.  

I believe that right now some authorization work happens in the
authentication/binding stage in the GetKeys function (i.e., if there isn't
a ViceID mapping for the authentication identity, reject authentication). 
I do not think the authorization stage in GetTokens is explicit, and it
should be made so.  At this point, the user is identified by a Vice ID (an
integer comparable to a local UNIX uid), and that is probably the best
argument to any request for authorization.  Presumably this would be a
convenient stage for PAM to kick in, as a central repository for
authorization information?  Possible arguments passed to PAM might
include: 

	Vice ID
	Method of authentication (password,kerbIV,kerbV,etc...)
	Perhaps a source IP, etc.

In Coda, as with UNIX in general, the username is somewhat spurious to the
process -- it is just a convenient way of figuring out the uid (or viceid
in Coda) for the purposes of the human sitting there.  How can PAM fit
best into this authorization question?  (keeping in mind that Coda and AFS
were designed with closed servers in mind, so the host's
authentication/authorization configuration should be considered distinct
from that being used by the auth server).

  Robert N Watson 

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/
robert@fledge.watson.org              http://www.watson.org/~robert/