On Apr 20, 11:28am, Tillman Hodgson wrote:
} On Sun, Nov 28, 2004 at 01:17:03PM -0800, John Nemeth wrote:
} > On Apr 17, 12:30pm, Tillman Hodgson wrote:
} > } 
} > } As I said, PAM allows the odd app or two that might be preventing
} > } Kerberizing an environment completely to still work. It's a stop-gap
} > } measure until those legacy services can be properly migrated.
} > 
} >      I don't view PAM as a stop-gap at all.  The idea behind PAM is
} > that applications don't have to know anything about the myriad ways of
} > authenticating.  They just have to know PAM and PAM will take care of
} > the work of authenticating for them.
} 
} PAM only addresses the server side of authentication. For example, one

     PAM runs where the application wanting to do authentication is
running.

} of the powerful features of Kerberos is ticket forwarding. It requires
} the client application understand Kerberos (or GSSAPI) well enough to
} actually forward the cached credentials rather than a username &

     Hmm, yes I see the problem.  Kerberos doesn't really fit into the
traditional UNIX way of doing things.  It seems that we need a new
protocol independent and method independent client/server
authentication protocol, where a server can tell a client what it wants
(i.e. prompt user for username and password, send Kerberos ticket,
etc.).  Of course, we then need an API that allows both the client and
server to do the authentication without any knowledge of the underlying
methods being used.  This sounds like we need a client/server version
of PAM where an application can open a connection to a network port,
kick off CSPAM to handle authentication, and then blast data across the
connection.

} password. A server-side-only PAM module won't provide features like
} this. This, in a Kerberos environment, pam_krb5 is a stop-gap measure.
} 
} I like PAM. However, pam_krb5 doesn't do what you seem to think it does
} ;-)

     I've nevered looked at it, so I don't know what it does.  Perhaps
somebody needs to come up with a new one.  Perhaps there is no good way
of doing it with current protocols and we need to invent CSPAM in order
to solve this problem.

}-- End of excerpt from Tillman Hodgson