[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.
> 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.
> * 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().
> That's assuming RADIUS attributes are important.
> If they are not, it would probably be very simple for a cooperating
> application to just grab the assertion, hand that to shibboleth and run
> with that.
If we are to do the work of resolving the assertion, then we may as well make the resolved attribute state available, whether it be the raw Shibboleth object or via gss_get_name_attribute().
Any application can always get the actual assertion by calling gss_get_name_attribute(name, "urn:ietf:params:gss-eap:saml-aaa-assertion").
-- Luke
|