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 > > > > > > > > > > >
