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

Re: Straw man: External authentication and PAM




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

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