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

Re: thinking about pam



   Date: Thu, 03 Oct 1996 18:03:33 -0700
   From: Brian Topping <topping@mauswerks.com>

   I am wondering how PAM expects to deal with user identities that are
   propagated via some other means than /etc/passwd.  I think this is the
   same question as how NIS works, and if so, is PAM going to be
   functionally similar in this regard?  For instance, I would like to be
   able to set up a user identity in kerberos and the home directory on an
   NFS server and expect the changes to be propagated to all machines that
   are part of the realm.

Well, each PAM module deals with it in its own way.  This is typically
done using mechanism-specific calls.  So, for example, the Kerberos PAM
module will make kerberos specific calls.  An NIS PAM module would make
NIS calls to get the passwd entry.  (Actually, in real life NIS
functionality is folded into the Unix PAM module, since all of the
processing after getting the passwd entry is the same.)

The point is that the PAM interface is the abstraction layer between the
mechanism-independent and mechanism-specific code.  

   In my shamelessly stolen graphic from Andrew's web page, my
   understanding of this is that the auth module below would use GSSAPI,
   but then map against an acct table that stores information about home
   directory, user's full name and shell.

No, the GSSAPI is very much misunderstood.  The GSSAPI is a generic
mechanism for handling client/server authentication, just as PAM is a
generic mechanism for handling login authentication, authorization, and
session management.  The two problem domains are distinct.  

The assumption with GSSAPI is that the user does **not** need to type
any login data in order to perform the authentication.  The
authenticaion is presumed to happen using cryptographic means: Kerberos
(using Needham-Schroder key exchange), SPKM (using public-key X.509
certificates), etc.  Hence, the GSSAPI does *not* support the concept of
a conversation function.  Further, the GSSAPI assumes that some other
mechanism will set up the initial credentials (Kerberos tickets, your
decrypted private-key component for your X.509 certificate, etc.).
For example, this might be done at login time, when you type your
password --- by a PAM module!  After you get your Kerberos tickets (or
your SPKM credentials, or whatever), then you can run application
programs which use those cryptographic credentials to securely establish
a secure, encrypted connection --- all without sending a password
across the network in the clear.

Does that make more sense to you now?

							- Ted



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