cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Maczuga (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
Date Fri, 14 Oct 2016 14:05:20 GMT

    [ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575434#comment-15575434
] 

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
(v6.3.4#6332)

Mime
View raw message