On Fri, Jan 30, 2009 at 11:21 AM, Benjamin Henne <he...@rvs.uni-hannover.de> wrote: > >> Can you elaborate how exactly you combine both attributes and do a >> authorization based on those attributes? > > Looking at the current setup and upcoming extension of our grid > infrastructure we have > * user attributes from VOMS > * attributes as attribute certificates in proxy certificates for Globus > and gLite, VOMS attributes as SAML assertions for UNICORE 6 > * concerning Globus, it will be an attribute push via the proxies > > At the moment we will not use GridShib (CA/ST) because of the version > mismatch: VOMS SAML asserting SAML2 vs. GridShib supporting SAML1.
Assuming all the stars align with respect to Google Summer of Code, we should be able to provide this capability by the end of summer 2009. > It > would be nice to integrated VOMS and Shibboleth SAML assertions into the > proxy and push them to the resources, but here again is the SAML version > problem. Shibboleth-issued SAML tokens are altogether different. The use of VOMS requires an X.509-based PKI, which leads to certain types of SAML tokens (containing <ds:X509SubjectName> elements). Shibboleth knows nothing of X.509-based PKI, so the SAML tokens obtained from a Shibboleth Attribute Authority would look very different. Moreover, in the GridShib model, Shibboleth-issued SSO assertions (yet another type of SAML token) are nested in the Advice element of another SAML assertion (as you, Benjamin, know very well :). As it turns out, a SAML V2.0 assertion can be nested in the Advice element of a SAML V1.1 assertion, and that is probably how this feature will be implemented at first (because it's simplest). No promises when this feature might appear, however. Tom
