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

Straw man: External authentication and PAM

Ok, so, as I think of this problem (see recent threads re: XSSO,
Kerberos, etc...) these are the solutions I can think of.

To state the problem one more time:

When an application authenticates the user externally to PAM, perhaps
because it's using a system that is not based on the service validating
a password, how can the application communicate to PAM the relevant
information about the external authentication so PAM could better
handle username mapping and authorization?

So the three ways I can think of right now, to deal with this problem:

1. Do nothing. Let the application convert GSS-API principal names to a
   username, let it set the PAM_USER item, perhaps it could set some
   PAM environment variable(s) to give hints to some module and let it
   call pam_authenticate().

   Thus it would be the responsibility of some PAM module (e.g.,
   PAM_KRB5) and the administrator to have pam_authenticate() succeed
   with no or minimal prompting of the user, provided the various items
   and/or PAM environment variables are set right.

2. Export pam_set_data() to applications so they can communicate with
   PAM modules using pam_set_data(). Otherwise (2) would be the same as

3. Extend the PAM API with a new function whose arguments are the
   relevant parameters of the external authentication that has been
   performed. Such a function might be called pam_gss_authenticated() or
   pam_authenticated(). A corresponding SPI would be required.

I think (1) just might have to do. (2) could do as well; I don't see why
pam_set_data() should not be available to applications.

(1) and (2) would be easy to implement, though they would require some
cooperation between the applications and the modules in the form of
naming conventions for env vars (1) or pam data (2).

(3) is probably harder to justify, but it would make the PAM interface
clearer, at least in this realm. Also, modules could act immidiately
when pam_sm_gss_authenticated() is called and maybe setup username/token
mappings at the time that pam_gss_authenticated() is called, rather than
later when pam_authenticate() is called. And pam_authenticate() would
not have to be called at all.

If pam_set_data() were exported to applications it might be nice to have
a corresponding SPI, pam_sm_set_data() so modules could act immidiately,
if need be, when an application uses pam_set_data() to communicate with
the modules.

Sun seems to be handling this problem as in (1) in Solaris 8.

Essentially there is a service name, 'ktelnet', which has pam_krb5 first
in the stack with 'acceptor' as an argument. Like so:

ktelnet auth required /usr/lib/security/$ISA/pam_krb5.so.1 acceptor

I have a hunch that 'acceptor' means: return PAM_SUCCESS immidiately.
Sun's SEAM's ktelnetd uses a login.krb5 program, rather than /bin/login,
just like MIT's Kerberos stuff (SEAM is based on MIT's code). So it
would seam that SEAM's login.krb5 sets the PAM service name to 'ktelnet'
or 'krlogin' and so on and so forth. I wonder just how other aspects of
the Kerberos authentication that ktelnetd may or may not have performed
are communicated to login.krb5 and from there to PAM and PAM_KR5.



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