Re: [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?
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
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
SAML 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>
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
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
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,
SAML the 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
participants (2)
-
Duane Merrill -
weizhong qiang