gss_pname_to_uid: is that the right interface

[Sam Hartman]

>>>>> "Danilo" == Danilo Almeida <dalmeida at MIT.EDU> writes:

    Danilo> Sam wrote:

    Danilo> 2) What are the desired use cases for gss_pname_to_uid and
    Danilo> gss_localname?  (Are they really about getting a uid and
    Danilo> local username?)

krb5_aname_to_lname.
My use case is logging into an ssh server sending a null username as
described in RFC 4462. 
That is, I know I want to log in, but I don't know what account my gss
context will be mapped to.
The same use case comes up in SASL; what authorization identity should
my authentication identity correspond to.


    Danilo> 3) Is gss_localname effectively the equivalent of doing a
    Danilo> gss_get_name_attribute with some well-known attribute for
    Danilo> the local udername?

That's what the mechglue does.
A mechanism can do more if it likes.
In practice, I often think that a mechanism will choose to do the heavy
lifting in gss_accept_sec_context and memoize the result in a name
attribute.

If you are a fairly platformy mechanism like krb5, you may well do a lot
that is mechanism specific.  If you're a fairly non-platformy mechanism,
you may not.  Both krb5 and gss-eap have things they'd kind of like to
do here.  gss-eap might be able to get out of this business if we moved
the Shibboleth SP from gss-eap into the mechglue, but today, gss-eap
does have a fairly platformy component in terms of the Shibboleth SP.

    Danilo> Adding OS authorization notions such as username or uid as a
    Danilo> new calls into GSSAPI seems like a really bad idea.  My
    Danilo> understanding is that gss_get_name_attribute() is supposed
    Danilo> to avoid having to do that.  Any such info could be derived
    Danilo> from the security context by an application introspecting
    Danilo> into the security context (potentially via some helper
    Danilo> library code that is not part of the GSS API implementation
    Danilo> calling into gss_get_name_attribute or other GSS calls).
    Danilo> Alternatively, an authdata plugin could just add the
    Danilo> OS-specific info as an attribute (potentially based on other
    Danilo> attributes added by other authdata plugins) so that the
    Danilo> application can just use gss_get_name_attribute() to get the
    Danilo> new attribute that has the new auth info.  I think that
    Danilo> matches what Nico and Sam have stated.

I respectfully disagree that adding this call is a bad idea.  It's
something that a lot of applications want to do, and I'm not actually
sure the mechanism behavior will always resolve to something as simple
as a name attribute lookup.  In some sense, a mechanism could make a
name attribute lookup as complex as it likes.

However, my dominant argument is that making things easy for the users
of your API should drive API design. Since there are reasonable default
implementations, this does not complicate mechanisms unless the
complexity is needed.  It definitely simplifies applications.  There
have been patches floating around in this space for ssh since 2006 or
so. There's a lot of SASL complexity surrounding this issue.  NFS
(particularly gssd) has needs in this area.  Finally,a lot of SSPI is
dedicated to a similar problem; the Microsoft approach is quite
different, but it is an argument for applications needing solutions to
this provided by the platform.

I'd buy an argument that this should be provided by convenience
libraries rather than the GSS. When we find ourselves with such a
convenience library with portability approaching that of GSS, we can
start shifting functionality--particularly new functionality
there. Today, though, arguing that this belongs outside of gss is an
argument against a portable solution.

--Sam