WSS4JInIntereptor does not always set the 'best' Principal as SecurityContext Principal

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.