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 (1). 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. Thoughts? Nico --
