Grzegorz Maczuga commented on CXF-7088:

Message is generated on Oracle Api Gateway (so you can put in the message 
whatever you want) and received by CXF.
It is just the proof that what was previously encrypted in message sample is 
not SAML Assertion (as you suspected) but Username Token.
Thus still we have not-encrypted SAML Assertion that is processed by CXF with 
SignedEncryptedSupportingTokens wrapping SAML Assertion in binding policy. 
Moreover as you pointed out - there is Username Token which is not in policy 
and shouldn't be there (but it is and I expect to be just ignored)?

We will remove Username Token and see what happen then.

> SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being 
> accepted
> ----------------------------------------------------------------------------------
>                 Key: CXF-7088
>                 URL: https://issues.apache.org/jira/browse/CXF-7088
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.0.6
>            Reporter: Grzegorz Maczuga
>            Assignee: Colm O hEigeartaigh
>         Attachments: messageNoEncryption.txt, message_anonymous.txt, 
> policy.txt
> In WS-Policy that is used by service we have defined 
> <SignedEncryptedSupportingTokens/>
> Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion 
> that is inside WS-Security section of the message SOAP Header should be 
> encrypted (not only signed).
> Message with SAML that is NOT encrypted is currently accepted by CXF even 
> while policy defines <SignedEncryptedSupportingTokens/>
> Question is: does SAML assertion fall into "SupportingTokens" category and 
> should be encrypted as well?
> What is your view on that? Is that a bug in Neethi?
> See 
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566
> Signed, encrypted supporting tokens are Signed supporting tokens (See section 
> 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. 
> Element Encryption SHOULD be used for encrypting the supporting tokens.
> The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax 
> of sp:SignedSupportingTokens only in the name of the assertion itself. All 
> nested policy is as per the sp:SignedSupportingTokens assertion.

This message was sent by Atlassian JIRA

Reply via email to