[
https://issues.apache.org/jira/browse/CXF-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3444.
-----------------------------------
Resolution: Fixed
> WSS4JInIntereptor does not always set the 'best' Principal as SecurityContext
> Principal
> ---------------------------------------------------------------------------------------
>
> Key: CXF-3444
> URL: https://issues.apache.org/jira/browse/CXF-3444
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.3.3
> Reporter: Sergey Beryozkin
> Assignee: Sergey Beryozkin
> Priority: Minor
> Fix For: 2.4, 2.3.4
>
>
> David Zhang reports:
> "At the end of the method is a for-loop over the wssEngineResults. If
> withCallbacks is false then the UsernameToken should be put in the message.
> **The Problem is, the first Principal found is not the UsernameTokenPrincipal
> but the DerivedKeyPrincipal**. This triggers creation of a security context
> and breakes the for-loop. The second wssEngineResult would have been the
> UsernameTokenPrincipal."
> The actual problem is that a Principal such as WSUsernameTokenPrincipal which
> is more likely to help at the SecurityContext level is not set as a
> SecurityContext principal.
> This does not happen when a public key was used to encrypt the token.
> The solution is simply try to ignore a DerivedKey principal (used solely for
> encrypting) if possible, when setting SecurityContext. All the principals
> will still be available on the message as before.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
