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