[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 Thu, Aug 24, 2000 at 05:04:02PM -0700, Andrew Morgan wrote:
> Nicolas Williams wrote:
> > I imagine telnetd or ftpd going through this sequence:
> > 
> >  - accept connection, perform Kerberos or GSS-API (likely Kerberos)
> >    authentication
> 
> Before we go there. Is there any reason why we couldn't pursue the idea
> of implementing GSS's authentication in a PAM module? I've just had an
> hour to catch up on the pam-list fraction of the kerberos thread, and I
> didn't see anything that touched on this.

Actually, I did broach the idea of integrating GSS-API into PAM to Sun.
No answer so far :(

I'm not sure it's worth doing that however. GSS-API is strictly about
remote authentication, whereas PAM is also about authorization and
session management and has room for lots of things. GSS-API does what
it does rather well and probably doesn't need to be messed with. But the
data involved is of use to PAM.

The one advantage to integrating GSS-API with PAM would be that there
would be no need to call pam_gss_authenticated() or anything like that:
PAM would get at the data automagically as the GSS-API exchange
completes. And it's not just principal names and QoPs we're talking
about, since GSS-API has a provision for credentials forwarding (as in
Kerberos TGT forwarding), PAM could get at any forwarded credentials
first and do the right thing with them.

Any such integration could simply be a thin layer atop GSS-API that
communicates the relevant data to PAM. So pam_gss_authenticated() or
something like that would still make sense as a building block.

I'm not sure there's much room for a tighter integration of GSS-API and
PAM, not because things won't jibe but because PAM has little or nothing
to bring to GSS-API whereas GSS-API has something to bring to PAM
(data).

Hmmm, then again, one could have a GSS-API standard mechanism for doing
PAM interactive and binary prompts remotely via GSS-API. Protocols that
already handle interactive username/password prompting wouldn't need
that, but new protocols certainly could be made simpler if they only
have to deal with GSS-API, letting the underlying GSS-API plug-in
mechanisms do the rest.

Much to think about. Why can't I go to sleep? :(

> If I read your proposal, it sort of looks like:
> 
>   - have something else manage authentication
>   - use PAM too.
> 
> I'm personally more interested in extending PAM to be general enough to
> deal with more interesting authentication schemes (as modules).

I can certainly understand that. And I agree.

> What stands in the way of doing that?

Nothing. See above. Well..., for one, there's more than just GSS-API;
some apps do straight Kerberos or straight NTLM without bothering with
GSS-API, so we shouldn't limit ourselves to GSS-API. If you go back to
my suggestion og pam_gss_authenticated(), it would only receive
information, and if the app didn't use GSS-API it can still create
GSS-API objects to represent what went on.

GSS-API, BTW, for those of you who don't know, is just a standard for
wrapping and unwrapping tokens exchanged during authentication in
network protocols in a way that is independent of the authentication
mechanism actually being used. The C API for GSS-API is rather simple
and well thought out, IMNSHO (don't be scared by the fact that there's
something like 69 functions), with a few minor shortcomings, primarily
in that the underlying mechanisms need to be exposed to the app a bit
more (e.g., there's no mechanism enumeration API).

GSS-APIed apps simply go through a loop where they exchange tokens
until the underlying mechanism informs GSS-API that authentication is
complete; GSS-API then informs the apps and then they proceed with life
as usual (well, GSS-API also provide functions for doing cryptographic
integrity and/or encryption afterwards, if desired by the apps).

> Cheers
> 
> Andrew
> 

Thanks,

Nico
--





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