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
--