ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Signed SAML tokens generate incomplete SignatureConfirmation results -- bug?
Date Mon, 16 Sep 2019 13:52:59 GMT
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
>
>
>
>
>

Mime
View raw message