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 <ntel...@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 <cohei...@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 > > > > > > > > > > > > > > > > > >
