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