Thank you for your response. This relates to the other recent threads here (PAM and Kerberos, and the thread about pam_acct_mgmt()). Think of a kerberized, PAMified telnetd. With such applications authentication may happen outside the PAM framework, but information about the way the user was authenticated might still be useful in account management. Wouldn't it be useful if a PAM module could do the .k5login checks and such things that MIT's telnetd and login.krb5 do without PAM? Wouldn't it be useful to be able to set policies, via pam.conf, about GSS-API/Kerberos/SRP/etc authentication where there is no password token that PAM can validate? After all, PAM does have an authorization component and I would like kerberized services to use that. I don't think it's enough to call pam_acct_mgmt() without calling pam_authenticate() because there's useful data about the external authentication mechanism that can be considered in authorization. For example: Kerberos user principal names; quality of protection negotiated for the session (e.g., session encryption). Similarly with password expiration as PAM should have knowledge about the source of the user's credentials in order to update them or even to know that they must be changed! And then PAM must map the local username to the user's principal name, something the application would already know. Now, I saw pictures (Figs. 4-5 and 4-6) in the XSSO documentation showing how XSSO would be involved in accessing remote services. The pictures show a client accessing a remote service and using GSS-API for authenticating to the remote service; the remote service is then shown using the XSSO layer. One would wonder how the remote service would interact with XSSO, but this is not described nor is there anything in XSSO which might help, other than NOT using pam_authenticate(); one also wonders what use the pam_[gs]et_mapped_*() calls are in such a scenario since there is no easy way to inform XSSO of the parameters involved in the GSS-API authentication of the client. Yes, I imagine the application could pass such information via the PAM_RUSER item, but that approach seems limiting. Somebody had to be on that committee, and surely they can explain this. My suggestion of a pam_gss_authenticated() call would give applications a way to inform PAM of the relevant information about how the user was authenticated. Alternatively there could be a set of new PAM items. Nico On Tue, Aug 22, 2000 at 01:02:18PM -0700, Andrew Morgan wrote: > XSSO, so far as I can tell, is a document written by a committee more > interested in publishing a document than creating a meaningful API. > > What problem (details please) are you trying to solve? > > Thanks > > Andrew > > Nicolas Williams wrote: > > > > Come on, someone on this list must know something about XSSO. Heck, > > there's even stubs in LinuxPAM for XSSO extensions. > > > > I can see the use of pam_authenticate_secondary() and pam_get_mapped_* > > and so on, but that's for tasks such as getting Kerberos tickets when > > Kerberos isn't your primary form of authentication. > > > > I think something like, say, pam_gss_authenticated() is needed. It's > > arguments would be a PAM handle, a GSS mechanism OID (gss_OID_desc), a > > GSS QoP OID and a principal name (gss_name_t). > > > > Applications that use Kerberos directly instead of GSS-API could still > > use pam_gss_authenticated() by converting the KRB5 principal name into a > > gss_name_t and by getting the relevant OIDs. > > > > Nico > > > > On Mon, Aug 21, 2000 at 03:48:31PM -0400, Nicolas Williams wrote: > > > > > > So, I've been looking at XSSO [*], the X/Open PAM-based single sign-on > > > spec. I like their pretty SSO pictures, and particularly the one where > > > an application uses GSS-API to authenticate to a remote service which > > > then uses XSSO to validate the client. > > > > > > I'm looking for how such a service would use XXSO (PAM) in that case. It > > > doesn't seem like there is an API for informing XSSO of the GSS-API > > > authentication information (mechanism(s), client principal(s)) so XSSO > > > can correctly authenticate and authorize the client. > > > > > > Can someone enlighten me as to the above? > > > > > > [*] http://www.opengroup.org/pubs/catalog/p702.htm > > > > > > Thanks, > > > > > > Nico > > > -- > > > > > > . > > -- > > > > _______________________________________________ > > > > Pam-list@redhat.com > > https://listman.redhat.com/mailman/listinfo/pam-list > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list --
