On Mon, Sep 13, 2010 at 06:26:58PM +0200, Luke Howard wrote:
> [Moving discussion to moonshot-community.]
>
> The discussion concerns how to expose the resolved attribute state and
> assertion for cooperating applications that are also using Shibboleth.
> In the current implementation, attributes and the actual assertion are
> both available through get_gss_name_attribute() (as one would expect).
> However, it is also possible to use gss_map_name_to_any() to retrieve
> the underlying Shibboleth objects. Sam noted that this may be fragile
> owing to C++ ABI issues.
Hadn't we decided to get rid of gss_map_name_to_any()?
> > I wonder if the story for cooperating applications that want to use
> > shibboleth should look something like the following:
> >
> > * Application sets a credential option telling the GSS mechanism that
> > it shouldn't do anything other than expose the assertion and RADIUS
> > attributes
>
> Surely this would be a context option? I'm not sure how the acceptor
> credential handle (the only credential input on the acceptor side) is
> related to how the initiator name is treated. I'm not sure if I really
> see the point of this option though unless you can identify a case
> where not resolving the assertion is useful.
The context doesn't exist on which to set the option before the context
tokens are exchanged. You might think this is a design flaw in the
GSS-API, but IMO this is something that belongs in the credential, or,
rather, in the name (gss_name_t) object. The name object, after all, is
bound into the credential handle as well.
Consider a library API where you can hand the library a GSS-API
credential handle to use. Think of Cyrus SASL (which does, in fact, now
have an option for passing in a GSS-API credential handle). How would
you handle context-level options in this case? You can't. The
credential has to be, and is, the explicit "template" for security
contexts that one might build into a new version of the GSS-API.
In this case I believe that the option in question should be a name
attribute. "I want to be authenticated as Anonymous but with this one
assertion exposed" -- clearly this fits into the name attributes model.
> > * Application calls some utility function we provide that takes a
> > gss_name_t and gives us back the appropriate shibboleth state
>
> Naming extensions does define such a utility function,
> gss_map_name_to_any().
Actual attributes should be obtained via gss_get_name_attribute().
Attributes nested in attributes should also be obtained via
gss_get_name_attribute().
Pseudo-attributes could be obtained via gss_get_name_attribute(). But
they can be an open set, thus listing them all becomes a problem, and
that, IIRC, is ultimately the reason why I originally had
gss_map_name_to_any() (also, I guess I wanted the app developer to be
aware of the fact that a mapping is explicitly required, that an
attribute is "pseudo", not concrete).
My original intention for gss_map_name_to_any() was to use to obtain
POSIX UIDs/GIDs for SIDs that appear in the PAC. At the time ID mapping
struck me as an explicit operation that the application should request.
But there's no reason to have a GSS-API function specifically for that:
the application could just retrieve the PAC, or the individual SIDs
listed in it, then invoke non-GSS ID mapping functions. Or we could
have pseudo-name attributes corresponding to "POSIX UID" (and if the set
of pseudo-attributes is open, then we just don't list them, but the
application can still try to get at them).
Sam and I had a discussion about how far to go in terms of exposing
nesting of attributes, whether and how to represent the path to a given
attribute if it is nested in others, and so on. Sam, can you summarize
our conclusions from that chat?
Nico
--
|