[jira] [Resolved] (CXF-3444) WSS4JInIntereptor does not always set the 'best' Principal as SecurityContext Principal

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

     [ 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