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

Re: XSSO? How to communicate to XSSO/PAM external authentication info?



On Wed, Aug 30, 2000 at 04:54:05PM +0200, Ingo Luetkebohle wrote:
> On Tue, Aug 29, 2000 at 11:49:07PM -0400, Nicolas Williams wrote:
> > (2) was never part of the proposal.
> 
> Right -- sorry for messing that up.
> 
> Still, what I meant to say, is, that if an application needs integrity
> protection and/or encryption, PAM has no API to provide it. So, a
> secondary solution like GSSAPI or TLS is required.
> 
> > Adapting an app to use GSS-API generally requires protocol and code
> > changes.
> > Adapting an app to use PAM+binary prompts requires server-side code
> > changes only.
> 
> While that seems correct on the outside, everything that PAM can
> negotiate has to be specified in a protocol.

Hmmm, no, why? If there's a PAM module for an auth system not supported
by, say, FTP, and yet it's listed in FTP's PAM config then that module
will simply return PAM_IGNORE when it's pam_sm_authenticate() method is
called. Why? Because when that module asks ftpd if that auth system is
being used ftpd will answer "I don't know what you're talking about, so
NO".

>                                              So, the correct way to
> put it is "PAM+binary prompt requires no *additional* protocol
> changes". No brainer, if you ask me.

Ok.

> > Originally I suggested adding a pam_gss_authenticated() API. Then Andrew
> > asked if I could go further. I looked into the binary prompts, thought
> > about it and fell in love with it.
> 
> Thats something else entirely. I tried to argue that PAM does *too
> much* already and that all this integration stuff (wether done through
> an extra function or through binary prompts is not the issue) only
> arises because of that. The conclusion would be that the complete
> problem could be neatly sidestepped by *limiting* PAM to the things it
> does well. Which, in my personal and very humble opinion is: 1)
> authenticating *interactive* logins (e.g., login or xdm) and 2)
> authorizing arbitrary sessions.

I beg to differ. The problem I have with GSS-API and Kerberos and so on
is that you still have to map principal names to usernames, and that's
not always trivial. Moreover, you still have to support something like
.k5login and what if you want to replace .k5login? Well, then you have
to modify ftpd/telnetd/login.krb5 and so on, whereas with PAM you'd just
have to replace a single module. But PAM can't do that, yet.

So I argue that PAM, as it stands, is only good for authorizing
interactive sessions where the user is authenticated using basic auth.

It seems a few simple changes will allow PAM to get involved in the
authentication phase of sessions authenticated using Kerberos, NTLM and
so on.

The changes?:

 - export pam_set_data() and pam_get_data() to the PAM apps;

 - make libpam call pam data cleanup functions when pam_end is called,
   delaying the calling of cleanup functions when pam data is replaced;

 - establish conventions for modules to prompt apps, not for usernames
   and passwords, but for GSS-API/Kerberos contexts, tokens, creds,
   etc...;

 - in fact, binary prompts aren't all that necessary here, as long as
   pam_set_data() and pam_get_data() are available to the app for
   exchanging non-string data with PAM modules;

 - then make some utility functions to hide the conventions mentioned
   above (e.g., pam_gss_authenticated()).

Only the first two items are actual changes to PAM. And they're small
changes, methinks.

Is there any reason NOT to do this? I'm not convinced that this approach
is bad. In fact, I'm getting more and more convinced it's good. But it
wouldn't pay off till several apps where modified to use this approach.

> -- 
> Ingo Luetkebohle / 21st Century Digital Boy
> 


Nico
--





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