I took the time to go through archives of this mailing list.
This kind of problem has come up before and I can see that XSSO is
pretty much dead.
I think the X/Open XSSO people simply didn't think of this problem. The
pam_authenticate_secondary() and pam_?et_mapped_*() APIs seem to be
there mostly for the purpose of dealing with smartcard password
wallets.
The interface between services that use GSS-API and XSSO seems to have
been left unspecified.
Would you be interested in a specification for pam_gss_authenticated()
and the corresponding SPI or something like it that could be used as a
straw man?
Such an API could give meaning to the pam_get_mapped_*() and
pam_set_mapped_*() APIs.
I imagine telnetd or ftpd going through this sequence:
- accept connection, perform Kerberos or GSS-API (likely Kerberos)
authentication
- optionally set PAM_USER/PAM_RUSER items, perhaps using the
pam_get_mapped_username() API for obtaining PAM_USER from the GSS-API
client principal name
OR, perhaps the modules that consume the GSS auth info could set
PAM_USER, if not already set.
- call pam_gss_authenticated() with mechanism OID, QoP OID and client
principal name as arguments
- call pam_get_user()
- call pam_acct_mgmt()
- if it fails and the protocol allows for further prompting of the
client, then call pam_authenticate() then call pam_acct_mgmt()
again
- perform password aging, as per pam_acct_mgmt(), if the protocol
allows for it
- if all's ok proceed (fork()/exec(), call pam_open_session(), etc...)
Nico
On Tue, Aug 22, 2000 at 04:40:12PM -0400, Nicolas Williams wrote:
>
> 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
> --
>
> .
--
