[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?
weizhong qiang
weizhongqiang at gmail.com
Mon Mar 30 12:16:30 CDT 2009
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>
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090330/ff813deb/attachment-0001.html
More information about the Pgi-wg
mailing list