gss_pname_to_uid: is that the right interface
hartmans at MIT.EDU
Thu Sep 22 10:00:01 EDT 2011
>>>>> "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?)
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
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.
More information about the krbdev