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
