Nicolas Williams ha scritto: > > > 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 > -- > uau...good !! This is our problem....we use a cistron radius autheticating users via PAM. The main problem is that it's hard (for compatibily) to pass data others than pam-related variables, as the cli or the client ip address(yes, radius has an user ip address, a NAS ip addres and a proxy ip address!!!!) or the called number. solution 1) is the simpest way, but an application should known exactly what a module needs...I appreciate solution 2, as the free-radius does, i.e. he passes the Av pairs to a loadable module trought a stack..., the concept: an application should be able to share relevant data with the pam framework...the PAM items seem to be useful for unix-like authentication only. max
begin:vcard n:Liccardo;Massimiliano tel;cell:eeeehhhhh...... tel;work:06 71036620 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:mliccardo.c@mail.tim.it title:Security Pianist Free Consultant x-mozilla-cpt:;22288 fn:Massimiliano Liccardo end:vcard
