Hi Alan,
Thanks for posting Gabriele's response. My question involves only
item 2. Specifically, what does the <saml:SubjectConfirmation>
element on the X.509-bound VOMS-SAML token look like? It's a very
important question that impacts the relying party's ability to confirm
the subject.
For example, the following <saml:Subject> element is analogous to
what's found in an attribute certificate:
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
[email protected],OU=User,O=NCSA-TEST,C=US
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509SubjectName>
[email protected],OU=User,O=NCSA-TEST,C=US
</ds:X509SubjectName>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
That is, the value of the <saml:NameID> element is equivalent to the
subject DN of the AC while the <ds:X509SubjectName> element describes
a form of holder-of-key subject confirmation equivalent to what a VOMS
relying party's does today (or so I believe).
The reason I ask is that we (in the OGSA Authz WG) originally profiled
a VOMS-SAML token containing a <ds:X509Certificate> element, which is
fine for UNICORE (which doesn't rely on proxies), but clearly
<ds:X509Certificate> leads to circular reasoning at the RP (since the
SAML token is bound to a proxy).
Thanks,
Tom
On Tue, Feb 3, 2009 at 5:28 PM, Alan Sill <[email protected]> wrote:
> More information from one of the VO Project managers is below.
>
> Alan
> -------------------------
>
>>
>> Hi Alan,
>> there are 2 distinct things here
>>
>> 1) using the SAML v2 profile of XACML v2 to convey authorization
>> assertions from a PEP to a PDP. This is the authorization
>> interoperability effort, a collaboration between Globus, EGEE / INFN,
>> OSG / VO Services, and Condor:
>>
>> http://listserv.fnal.gov/scripts/wa.exe?A2=ind0901e&L=privilege_project&T=0&X=2B9777238D431DBE31&Y=garzogli%40fnal.gov&P=1906
>>
>> 2) embedding SAML v2 assertions in certificate proxies to convey user
>> attributes, instead of using VOMS attribute certificates. This effort is
>> led by INFN / VOMS.
>>
>> In principle, a natural extension of (1) would be using the SAML
>> assertions in the proxies from (2) to obtain authorization decisions.
>> That would work almost immediately with XACML-based PDPs, such as GPBox
>> and gJAF. For non-XACML-based PDP, such as GUMS or SAZ, it would require
>> integration work.
>>
>> Hope this helps
>> Cheers
>> Gabriele
>>
>>
>> Alan Sill wrote:
>>>
>>> Hi gents,
>>>
>>> Can you comment on the following interchange currently taking place in
>>> the glite-discuss and gt-user lists, please? What is the current
>>> state of SAML2 with respect to the joint authorization project and
>>> specifically VOMS?
>>>
>>> Thanks!
>>>
>>> Alan
>>
>
