You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ws.apache.org by Nimish Telang <ni...@telang.net> on 2019/09/07 18:10:38 UTC
Signed SAML tokens generate incomplete SignatureConfirmation results
-- bug?
Hi all,
If we enable signature confirmation element generation, the SignatureConfirmation Action will generate Elements for every signature including signed SAML assertions/tokens. This has a few issues, namely:
1. The SAML assertion processor does not add a “signature-value” ( WSSecurityEngineResult.TAG_SIGNATURE_VALUE) so the signature confirmation associated with the signed assertion has no attribute value, which according to the spec, is: “If this attribute is specified with an empty value, the initiator SHOULD interpret this as incorrect behavior and process accordingly”
2. A signatureconfirmation must be generated for every ds:Signature processed including, as far as I can tell, a signed saml assertion.
This results in bogus signatureconfirmations. I don’t know which part is wrong, but I do know a signature confirmation w/o a value is busted.
Based on reading the source, the SAMLTokenSigned processor should fill in the signature value.
Nimish
Re: Signed SAML tokens generate incomplete SignatureConfirmation
results -- bug?
Posted by Colm O hEigeartaigh <co...@apache.org>.
On consideration, I think it's probably a good idea to support
SignatureConfirmation properly for signed SAML Elements. I've merged a fix
to master and to the 2.2.x branch, so please grab the latest SNAPSHOT and
see if it works for you.
https://issues.apache.org/jira/browse/WSS-658
Colm.
On Mon, Nov 4, 2019 at 4:41 PM Nimish Telang <nt...@gmail.com> wrote:
> Hi,
>
> Apologies for the delay:
>
> When this attribute is
> not present, the
> initiator SHOULD interpret this to mean that the response is based on a
> request that was
> not signed."
>
> Isn't this an issue with not filling the value attribute? The request SAML
> token _was_ signed. Maybe the request was signed too, and that gets its own
> SignatureConfirmation.
>
> "Compliant responder implementations that support signature confirmation,
> MUST include a
> <wsse11:SignatureConfirmation> element inside the <wsse:Security> header of
> the
> associated response message for every <ds:Signature> element that is a
> direct child of the
> <wsse:Security> header block in the originating message."
>
>
> I would think that the right thing to do for internally (Enveloped)
> signed SAML tokens is to not issue a SignatureConfirmation at all for that
> ds:Signature element, rather than one with no @Value, as it implies the
> "request is not signed".
>
> I've basically created my own Action that doesn't issue
> SignatureConfirmations for signed saml tokens, but it's really a hack that
> edits just one line in the default one (can't be changed by config).
>
> Nimish
>
> On 2019/09/16 13:52:59, Colm O hEigeartaigh <co...@apache.org> wrote:
> > Hi,
> >
> > Answers inline.
> >
> >
> > > 1. The SAML assertion processor does not add a “signature-value” (
> > > WSSecurityEngineResult.TAG_SIGNATURE_VALUE) so the signature
> confirmation
> > > associated with the signed assertion has no attribute value, which
> > > according to the spec, is: “If this attribute is specified with an
> empty
> > > value, the initiator SHOULD interpret this as incorrect behavior and
> > > process accordingly”
> > >
> > >
> > I think you are misinterpreting the spec here. What is meant here is
> that a
> > @Value attribute is present but with an empty value. Sending a
> > SignatureConfirmation element with no Value attribute is valid:
> >
> > "This optional attribute contains the contents of a <ds:SignatureValue>
> > copied from
> > the associated request. If the request was not signed, then this
> attribute
> > MUST NOT be
> > present. If this attribute is specified with an empty value, the
> initiator
> > SHOULD interpret
> > this as incorrect behavior and process accordingly. When this attribute
> is
> > not present, the
> > initiator SHOULD interpret this to mean that the response is based on a
> > request that was
> > not signed."
> >
> >
> >
> > >
> > >
> > > 1. A signatureconfirmation must be generated for every ds:Signature
> > > processed including, as far as I can tell, a signed saml assertion.
> > >
> > >
> > The spec is a bit ambiguous on this, but I'm leaning towards thinking
> that
> > WSS4J does the right thing by not including signature values for
> > (internally) signed SAML Assertions. From the spec:
> >
> > "Compliant responder implementations that support signature confirmation,
> > MUST include a
> > <wsse11:SignatureConfirmation> element inside the <wsse:Security> header
> of
> > the
> > associated response message for every <ds:Signature> element that is a
> > direct child of the
> > <wsse:Security> header block in the originating message."
> >
> > Colm.
> >
> >
> >
> > >
> > > 1.
> > >
> > >
> > >
> > > This results in bogus signatureconfirmations. I don’t know which part
> is
> > > wrong, but I do know a signature confirmation w/o a value is busted.
> > >
> > >
> > >
> > > Based on reading the source, the SAMLTokenSigned processor should fill
> in
> > > the signature value.
> > >
> > >
> > >
> > > Nimish
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Signed SAML tokens generate incomplete SignatureConfirmation results -- bug?
Posted by Nimish Telang <nt...@gmail.com>.
Hi,
Apologies for the delay:
When this attribute is
not present, the
initiator SHOULD interpret this to mean that the response is based on a
request that was
not signed."
Isn't this an issue with not filling the value attribute? The request SAML token _was_ signed. Maybe the request was signed too, and that gets its own SignatureConfirmation.
"Compliant responder implementations that support signature confirmation,
MUST include a
<wsse11:SignatureConfirmation> element inside the <wsse:Security> header of
the
associated response message for every <ds:Signature> element that is a
direct child of the
<wsse:Security> header block in the originating message."
I would think that the right thing to do for internally (Enveloped) signed SAML tokens is to not issue a SignatureConfirmation at all for that ds:Signature element, rather than one with no @Value, as it implies the "request is not signed".
I've basically created my own Action that doesn't issue SignatureConfirmations for signed saml tokens, but it's really a hack that edits just one line in the default one (can't be changed by config).
Nimish
On 2019/09/16 13:52:59, Colm O hEigeartaigh <co...@apache.org> wrote:
> Hi,
>
> Answers inline.
>
>
> > 1. The SAML assertion processor does not add a “signature-value” (
> > WSSecurityEngineResult.TAG_SIGNATURE_VALUE) so the signature confirmation
> > associated with the signed assertion has no attribute value, which
> > according to the spec, is: “If this attribute is specified with an empty
> > value, the initiator SHOULD interpret this as incorrect behavior and
> > process accordingly”
> >
> >
> I think you are misinterpreting the spec here. What is meant here is that a
> @Value attribute is present but with an empty value. Sending a
> SignatureConfirmation element with no Value attribute is valid:
>
> "This optional attribute contains the contents of a <ds:SignatureValue>
> copied from
> the associated request. If the request was not signed, then this attribute
> MUST NOT be
> present. If this attribute is specified with an empty value, the initiator
> SHOULD interpret
> this as incorrect behavior and process accordingly. When this attribute is
> not present, the
> initiator SHOULD interpret this to mean that the response is based on a
> request that was
> not signed."
>
>
>
> >
> >
> > 1. A signatureconfirmation must be generated for every ds:Signature
> > processed including, as far as I can tell, a signed saml assertion.
> >
> >
> The spec is a bit ambiguous on this, but I'm leaning towards thinking that
> WSS4J does the right thing by not including signature values for
> (internally) signed SAML Assertions. From the spec:
>
> "Compliant responder implementations that support signature confirmation,
> MUST include a
> <wsse11:SignatureConfirmation> element inside the <wsse:Security> header of
> the
> associated response message for every <ds:Signature> element that is a
> direct child of the
> <wsse:Security> header block in the originating message."
>
> Colm.
>
>
>
> >
> > 1.
> >
> >
> >
> > This results in bogus signatureconfirmations. I don’t know which part is
> > wrong, but I do know a signature confirmation w/o a value is busted.
> >
> >
> >
> > Based on reading the source, the SAMLTokenSigned processor should fill in
> > the signature value.
> >
> >
> >
> > Nimish
> >
> >
> >
> >
> >
>
Re: Signed SAML tokens generate incomplete SignatureConfirmation
results -- bug?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
Answers inline.
> 1. The SAML assertion processor does not add a “signature-value” (
> WSSecurityEngineResult.TAG_SIGNATURE_VALUE) so the signature confirmation
> associated with the signed assertion has no attribute value, which
> according to the spec, is: “If this attribute is specified with an empty
> value, the initiator SHOULD interpret this as incorrect behavior and
> process accordingly”
>
>
I think you are misinterpreting the spec here. What is meant here is that a
@Value attribute is present but with an empty value. Sending a
SignatureConfirmation element with no Value attribute is valid:
"This optional attribute contains the contents of a <ds:SignatureValue>
copied from
the associated request. If the request was not signed, then this attribute
MUST NOT be
present. If this attribute is specified with an empty value, the initiator
SHOULD interpret
this as incorrect behavior and process accordingly. When this attribute is
not present, the
initiator SHOULD interpret this to mean that the response is based on a
request that was
not signed."
>
>
> 1. A signatureconfirmation must be generated for every ds:Signature
> processed including, as far as I can tell, a signed saml assertion.
>
>
The spec is a bit ambiguous on this, but I'm leaning towards thinking that
WSS4J does the right thing by not including signature values for
(internally) signed SAML Assertions. From the spec:
"Compliant responder implementations that support signature confirmation,
MUST include a
<wsse11:SignatureConfirmation> element inside the <wsse:Security> header of
the
associated response message for every <ds:Signature> element that is a
direct child of the
<wsse:Security> header block in the originating message."
Colm.
>
> 1.
>
>
>
> This results in bogus signatureconfirmations. I don’t know which part is
> wrong, but I do know a signature confirmation w/o a value is busted.
>
>
>
> Based on reading the source, the SAMLTokenSigned processor should fill in
> the signature value.
>
>
>
> Nimish
>
>
>
>
>