[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 Sun, Aug 27, 2000 at 01:08:21AM +0200, Ingo Luetkebohle wrote:
> On Sat, Aug 26, 2000 at 04:58:22PM -0400, Nicolas Williams wrote:
> > So? Pam_gss would be issuing the binary prompt, and in such protocols
> > the service had better already know what auth type was negotiated. PAM
> > still would get to authorize the use of any particular authentication
> > type though, via pam_acct_mgmt().
> Ok, I re-read your original post and think I misunderstood it on first
> pass. Just to get this clear, you are suggesting a new GSSAPI
> mechanism ("PAM") which would be general in nature and could support
> arbitrary authentication mechanims, implemented in the usual PAM way
> as modules. Did I get that right this time?

I'm suggestion that apps that support authentication systems other than
basic (username/password) could use PAM in combination with PAM binary
prompts and a special PAM module for each such authentication system.

Imagine (simplified pam.conf extract):

ftpd	auth	sufficient	pam_gss.so
ftpd	auth	sufficient	pam_srp.so
ftpd	auth	sufficient	pam_something_else.so
ftpd	auth	required	pam_deny.so

And then imagine ftpd having a binary conversation function which
doesn't use the GSS-API C bindings at all (though it may have to know
how to, say, encode GSS-API tokens for use in the FTP protocol), or SRP,
or SOMETHING_ELSE. All ftpd would have to do is setup PAM (pam_start(),
maybe some pam_set_item() calls, etc...) then call pam_authenticate()
and let the pam_sm_authenticate() methods of the pam_gss et. al. modules
do the authentication work via the conversation function.

> If yes, the application obviously knows that it would have to
> negotiate for GSSAPI and then leave the rest to PAM. However, that
> seems like one step too many for me.

Why? See above. If you have to support multiple authentication systems
then this approach should simplify the code for the service.

If you only have to support GSS-API, then this approach should still
make for simpler code and it would make it easier to add something other
than GSS-API later.

> If no, I don't see how you'll fit a binary prompt into FTP-SEC.

I was confused about the purpose of binary prompts when I blabbed about
that. Ignore that suggestion...

> -- 
> Ingo Luetkebohle / 21st Century Digital Boy
> its easy to stop using Perl: I do it after every project


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