[Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?

Duane Merrill dgm4d at virginia.edu
Mon Mar 30 16:45:39 CDT 2009 

https://forge.gridforum.org/sf/go/doc15575?nav=1

-Duane

On Mon, Mar 30, 2009 at 5:41 PM, Tom Scavo <trscavo at gmail.com> wrote:

> Duane, can you post a pointer please?  Thanks.
>
> On Mon, Mar 30, 2009 at 5:37 PM, Duane Merrill <dgm4d at virginia.edu> wrote:
> > BTW, the original PGI Strawman contains some considerations for what
> exactly
> > what you are discussing, regarding a SOAP-SAML-attribute profile.
> >
> > -Duane
> >
> >
> >
> > 2009/3/30 weizhong qiang <weizhongqiang at gmail.com>
> >>
> >> hi,
> >>
> >> On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo at gmail.com> wrote:
> >>>
> >>> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang
> >>> <weizhongqiang at gmail.com> wrote:
> >>> >
> >>> > For a SAML Token which is compliant to SAML V1.1...
> >>> >
> >>> > For a SAML Token which is compliant to SAML V2.0...
> >>>
> >>> It should be noted that these examples from the WSS SAML Token Profile
> >>> are not normative.  Indeed, the SAML V2.0 token is not even
> >>> schema-valid.
> >>
> >> Thanks. I did not know that. But I also thought this part of
> specification
> >> in WS-Security is not so clearly defined.
> >>
> >>>
> >>> > 1. The signature for <saml:Reponse> could also be necessary, even
> >>> > though the
> >>> > integrity is guaranteed by TLS.
> >>>
> >>> That's unlikely, I think.  The Response is consumed by the requester
> >>> (it does not appear in the SOAP header) so there's really no need
> >>> (that I can see) to sign the Response if the request is made over
> >>> mutually authenticated TLS.
> >>>
> >>> > 2. xml attribute  xsi:type="saml2:KeyInfoConfirmationDataType" could
> be
> >>> > necessary for <saml2:SubjectConfirmationData/>
> >>>
> >>> As I recall, that type declaration is optional, but yes, its use is
> >>> recommended.
> >>>
> >>> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate>
> >>> > element, but it probably be better to just contain a <ds:KeyValue>,
> >>> > since
> >>> > the certificates chain of the "subject" is already supposed to be
> >>> > verified
> >>> > by the third-party authority (in this case, it is voms saml service),
> >>> > and
> >>> > then this public key is used to sign the soap message afterwards.
> >>>
> >>> I don't see what the certificate chain has to do with the use of the
> >>> <ds:X509Certificate> element in this case.  The latter requires the
> >>> presenter to prove possession of the private key corresponding to the
> >>> public key bound to the certificate.  What does that have to do with
> >>> the presented certificate chain?
> >>
> >> two types of verification here:
> >> 1. verify that "possession of the private key corresponding to the
> public
> >> key bound to the certificate"
> >> 2. verify that "possession of the private key corresponding to the
> public
> >> key bound to the certificate" + verify that the certificate is signed by
> >> trusted authority (in this case verification of certificates chain is
> >> needed.)
> >>
> >> What I meant is for SAML Token profile, step 2 is not needed.
> >>
> >>>
> >>> > For SOAP
> >>> > message verification on the rely-party side, the rely-party do not
> need
> >>> > to
> >>> > verify the certificates chain of "subject".
> >>>
> >>> I'm not sure I follow you.  How does the presenter of the SOAP request
> >>> (with SAML token in the SOAP header) authenticate to the SOAP
> >>> responder?
> >>
> >> "authentication" here could not be accurate.
> >> SOAP presentor authenticates (via TLS, or SOAP message authentication by
> >> using X.509 token) to 3-party authority (trusted by rely-party), and
> gets
> >> back SAML Token (with the presentor's public key, or certificate inside
> as
> >> part of <saml:SubjectConfirmation>); Then uses its' own private key to
> sign
> >> soap message; Afterwards rely-party can verify the signature to SOAP
> message
> >> (simple verification is needed, just verify that the private key which
> >> signes the SOAP message corresponds to the public key in the
> >> <saml:SubjectConfirmation>), as well as verify the signature to
> >> <saml:Assertion> (simple verification + verifying the certificate in
> >> <ds:Signature> is trusted).
> >>
> >>
> >>>
> >>> > <ds:KeyValue> is also convinient for proxy certificate, in my
> opinion.
> >>>
> >>> I don't see what <ds:KeyValue> gains you in this case, but I may be
> >>> missing something.  Unless you can provide a good reason for using
> >>> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in
> >>> that order.  The <ds:X509SubjectName> element is simplest for proxy
> >>> certificates, I think.  It is equivalent to the subject confirmation
> >>> implied in VOMS proxies, in fact.
> >>
> >> Probably <ds:KeyValue> can not gain more than <ds:X509Certificate>
> >> (formerly I supposed the <ds:KeyValue> should be standarlized) . But by
> >> using <ds:X509SubjectName>,  what is the way to get the public key,
> which is
> >> required when verifying the signature to SOAP message.
> >>
> >>>
> >>> In any event, I should point out that the SAML V2.0 Holder-of-Key
> >>> Assertion Profile is now in its formal Public Review period, and it
> >>> does not profile <ds:KeyValue>, so if you think that's an error of
> >>> omission, it would be good if you could submit a public comment to
> >>> that effect.
> >>>
> >>>
> >>>
> http://lists.oasis-open.org/archives/security-services/200903/msg00062.html
> >>
> >> Is any of the draft you mentioned in this link supposed to
> update/replace
> >> the WS-Security SAML Token 1.1 profile?
> >>
> >>
> >> Weizhong Qiang
> >>
> >>
> >>>
> >>>
> >>> > 4. Use <saml:Statement> instead of <saml:AttributeStatement>.
> >>>
> >>> Why?  The <saml:Statement> element is abstract so that would require a
> >>> type.  What type do you recommend (if not
> >>> saml:AttributeStatementType)?
> >>>
> >>> Tom
> >>>
> >>> > On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo at gmail.com>
> wrote:
> >>> >>
> >>> >> Hi Weizhong,
> >>> >>
> >>> >> Can you outline why you think the VOMS SAML assertion is not
> >>> >> compatible with the WSS SAML Token Profile?
> >>> >>
> >>> >> Thanks,
> >>> >> Tom
> >>> >>
> >>> >> PS. The comments quoted below mostly refer to a VOMS SAML assertion
> >>> >> bound to an X.509 proxy certificate (but the requirements are not
> the
> >>> >> same as a VOMS SAML assertion bound to SOAP header).
> >>> >>
> >>> >> On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang
> >>> >> <weizhongqiang at gmail.com> wrote:
> >>> >> > hi voms folks, all,
> >>> >> > The current voms SAML assertion is not compatible with WS-Security
> >>> >> > SAML
> >>> >> > Token profile. I would ask is there any plan to change it to make
> it
> >>> >> > be
> >>> >> > compatible? I ask this because I think if so, the SAML assertion
> can
> >>> >> > be
> >>> >> > used
> >>> >> > for SOAP message layer authentication, other than just including
> >>> >> > SAML
> >>> >> > attribute assertion.
> >>> >> >
> >>> >> >
> >>> >> > Thanks
> >>> >> > Weizhong Qiang
> >>> >> >
> >>> >> >
> >>> >> > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo at gmail.com>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Thanks to Benjamin for posting this VOMS-SAML response to
> gt-user.
> >>> >> >>  A
> >>> >> >> critique (of the SAML, not Benjamin :) follows.
> >>> >> >>
> >>> >> >> - Note that the output is a <samlp:Response> element, not a
> >>> >> >> <saml:Assertion> element.  This is wrong.  The requester must
> >>> >> >> consume
> >>> >> >> the response.  Not sure why this isn't happening.
> >>> >> >>
> >>> >> >> - The value of the <saml:Issuer> element in the response is a DN
> >>> >> >> but
> >>> >> >> the Format XML attribute is missing.  This is a bug.  The default
> >>> >> >> Format is "unspecified" but clearly this is not.
> >>> >> >>
> >>> >> >> - Second-level status codes are desirable so they can be echoed
> on
> >>> >> >> the
> >>> >> >> command line (if any).
> >>> >> >>
> >>> >> >> - Same comment about the <saml:Issuer> element in the assertion.
> >>> >> >>
> >>> >> >> - The use of SAML metadata requires that the Format on the
> >>> >> >> <saml:Issuer> element be "entity" but clearly it is not.  Thus
> the
> >>> >> >> use
> >>> >> >> of SAML metadata by the relying party is precluded.
> >>> >> >>
> >>> >> >> - Don't know if Shibboleth/OpenSAML can verify the signature
> (which
> >>> >> >> is
> >>> >> >> tricky business).  This is a future experiment that needs to be
> >>> >> >> done.
> >>> >> >>
> >>> >> >> - The <saml:SubjectConfirmation> element contains a
> >>> >> >> <ds:X509Certificate> element, which precludes the binding of this
> >>> >> >> holder-of-key assertion to a proxy certificate.  This is a bug.
> >>> >> >>  Use a
> >>> >> >> <ds:X509SubjectName> element instead (which causes the NameID
> >>> >> >> itself
> >>> >> >> to be redundant).
> >>> >> >>
> >>> >> >> - If the assertion is bound to a proxy certificate, the NotBefore
> >>> >> >> and
> >>> >> >> NotOnOrAfter attributes are redundant and superfluous.  In fact,
> >>> >> >> they
> >>> >> >> may be wrong since they must agree with the NotBefore and
> >>> >> >> NotOnOrAfter
> >>> >> >> fields of the proxy.
> >>> >> >>
> >>> >> >> - Since the client authenticated directly to the server, a
> >>> >> >> <saml:AuthnStatement> is desirable (not required, but potentially
> >>> >> >> useful at the relying party).
> >>> >> >>
> >>> >> >> - The NameFormat XML attribute on the <saml:Attribute> element
> >>> >> >> should
> >>> >> >> be "uri" not "unspecified".
> >>> >> >>
> >>> >> >> - The "xsi:" prefix on the <saml:AttributeValue> element is
> >>> >> >> undefined.
> >>> >> >>  This is a bug.
> >>> >> >>
> >>> >> >> - The <saml:AttributeValue> elements do not conform to the XACML
> >>> >> >> Attribute Profile (actually, I don't think the attributes conform
> >>> >> >> to
> >>> >> >> *any* SAML V2.0 attribute profile).
> >>> >> >>
> >>> >> >> Hope this helps,
> >>> >> >> Tom
> >>> >> >>
> >>> >> >> ---------- Forwarded message ----------
> >>> >> >> From: Benjamin Henne <henne at rvs.uni-hannover.de>
> >>> >> >> Date: Wed, Feb 4, 2009 at 1:59 AM
> >>> >> >> Subject: Re: [gt-user] SAML based VOMS Server
> >>> >> >> To: Tom Scavo <trscavo at gmail.com>
> >>> >> >> Cc: GT User <gt-user at globus.org>
> >>> >> >>
> >>> >> >>
> >>> >> >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol"
> >>> >> >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> >>> >> >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6"
> >>> >> >> InResponseTo="_qwertyuiopasdfghjklzxcvbn"
> >>> >> >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0">
> >>> >> >>  <saml:Issuer
> >>> >> >>
> >>> >> >>
> >>> >> >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN=
> voms3.gridlab.uni-hannover.de
> ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer>
> >>> >> >>  <Status>
> >>> >> >>   <StatusCode
> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
> >>> >> >>  </Status>
> >>> >> >>  <saml:Assertion
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> >>> >> >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"
> >>> >> >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0">
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de
> ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer>
> >>> >> >>   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> >>> >> >> <ds:SignedInfo>
> >>> >> >> <ds:CanonicalizationMethod
> >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> >>> >> >> <ds:SignatureMethod
> >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> >>> >> >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac">
> >>> >> >> <ds:Transforms>
> >>> >> >> <ds:Transform
> >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature
> "/>
> >>> >> >> <ds:Transform
> >>> >> >>
> >>> >> >>
> >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#
> "><ec:InclusiveNamespaces
> >>> >> >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
> PrefixList="ds
> >>> >> >> saml
> >>> >> >> xs"/></ds:Transform>
> >>> >> >> </ds:Transforms>
> >>> >> >> <ds:DigestMethod
> >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >>> >> >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue>
> >>> >> >> </ds:Reference>
> >>> >> >> </ds:SignedInfo>
> >>> >> >> <ds:SignatureValue>
> >>> >> >> ...
> >>> >> >> </ds:SignatureValue>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>
> >>> >> >>   <saml:Subject>
> >>> >> >>     <saml:NameID
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin
> >>> >> >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID>
> >>> >> >>     <saml:SubjectConfirmation
> >>> >> >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
> >>> >> >>       <saml:SubjectConfirmationData>
> >>> >> >>         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#
> ">
> >>> >> >>           <ds:X509Data>
> >>> >> >>             <ds:X509Certificate>...</ds:X509Certificate>
> >>> >> >>           </ds:X509Data>
> >>> >> >>         </ds:KeyInfo>
> >>> >> >>       </saml:SubjectConfirmationData>
> >>> >> >>     </saml:SubjectConfirmation>
> >>> >> >>   </saml:Subject>
> >>> >> >>   <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z"
> >>> >> >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/>
> >>> >> >>   <saml:AttributeStatement>
> >>> >> >>     <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles"
> >>> >> >>
> >>> >> >>
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue>
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue>
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">staff@
> /RVS/research/SAML</saml:AttributeValue>
> >>> >> >>     </saml:Attribute>
> >>> >> >>     <saml:Attribute Name="nationality"
> >>> >> >>
> >>> >> >>
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">German</saml:AttributeValue>
> >>> >> >>     </saml:Attribute>
> >>> >> >>     <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group"
> >>> >> >>
> >>> >> >>
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">/RVS/education</saml:AttributeValue>
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">/RVS</saml:AttributeValue>
> >>> >> >>       <saml:AttributeValue
> >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>> >> >> xsi:type="xs:string">/RVS/research</saml:AttributeValue>
> >>> >> >>     </saml:Attribute>
> >>> >> >>   </saml:AttributeStatement>
> >>> >> >>  </saml:Assertion>
> >>> >> >> </Response>
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >> _______________________________________________
> >> Pgi-wg mailing list
> >> Pgi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/pgi-wg
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090330/9e0480c3/attachment-0001.html

More information about the Pgi-wg mailing list