Question for the GSS intelligentsia.
As Luke (and I think Sam) are aware, we ran into a trouble spot adding
code to support Shibboleth attribute processing of GSS contexts,
specifically the inability to both export and import GSS names while
preserving naming extensions.
The problem we have is that in certain cases, the Shibboleth code will
want or need to move processing of the GSS information to a different
process from the GSS acceptor. In at least one case (the web), it's
mandatory based on the SP design. I had built some API support for this in
terms of GSS contexts and then learned that because of the security
properties of some mechanisms you can't export a context without
destroying the original.
I think we all agreed that the best API approach was to move just the
gss_name_t around between the processes, but I was told that there's no
support yet for importing composite names (due to a missing OID for the
GSS_C_NT_EXPORT_NAME_COMPOSITE name type?)
So my question is: how does this get fixed? Does somebody just have to
write an I-D to propose this for standardization?
In the mean time, I can't see any workaround for my web-based APIs,
because I have no choice but to avoid shipping the context around. We
avoided that problem in the non-web case because it's Luke mechanism code
calling into my code, and he prepares a partially constructed disposable
GSS context for that purpose.
There's no such workaround in the web case, because my code is picking up
a fully accepted context from Daniel's module and I can't trash it just to
process the naming extensions.
At this point, pending GSS name import support, I probably will need to
hack around this by extracting the GSS attributes on the Apache process
side and pickling them myself for export to the process where they'll be
chewed on. At least that seems like the only option.
-- Scott
|