On Mon, Mar 30, 2009 at 5:37 PM, Duane Merrill <
dgm4d@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@gmail.com>
>>
>> hi,
>>
>> On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <
trscavo@gmail.com> wrote:
>>>
>>> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang
>>> <
weizhongqiang@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@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@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@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@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@gmail.com>
>>> >> >> Cc: GT User <
gt-user@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@ogf.org>>
http://www.ogf.org/mailman/listinfo/pgi-wg
>>
>
>