axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From El Bog <>
Subject Re: [Axis2 1.4.1 / Rampart 1.4] AsymmetricBinding and SignedEncryptedSupportingTokens policy not appied on Usernametoken
Date Thu, 21 Jan 2010 15:52:48 GMT

Hello Nandana, thanks for you quick reply.

Here is the policy file I'm using (rampart config removed for
confidentiality issues) :
And here is an extract of the message sent that I monitored with tcpmon :
(body removed because irrelevant and confidential)

As you can see, the security header is not even included.

If I simply switch between <sp:SignedEncryptedSupportingTokens> and
<sp:SignedSupportingTokens>, here is what I get :

I suspected the code I mentioned to be responsible for it because using a
debugger, I followed the following path : ->

in :

        if(rpd == null || isSecurityValidationFault(msgCtx) || 
rmd.isInitiator(),false)) {
            Document doc = rmd.getDocument();
            WSSecHeader secHeader = rmd.getSecHeader();
            if ( secHeader != null && secHeader.isEmpty(doc) ) {

So In case I use a SignedEncryptedSupportingTokens, the isSecHeaderRequired
returns false, and the security header gets simply removed, which is exactly
what I observed.
Maybe its my description of the bug which is wrong, because not only is the
usernametoken not included, but the whole security header...

As you suggested, using SignedSupportingTokens I get what I expected since
usernametoken is always encrypted.

However, I have a few questions :

- I already read some messages from you in other threads where you explained
that the usernametoken 
is encrypted by default : could you please point me to a resource explaining
the reason for this? (if any..)
I read WS-SecurityPolicy 1.2 specs from oasis and could not find anything
stating that this is mandatory.
I need to explain and justify the xml policy file and the behaviour which is
observed to another industrial...
I am particulary concerned by the following point :
If the server on the over side uses another stack than Axis, won't he
possibly need to specify a policy which would use
SignedEncryptedSupportingTokens even though the one I use says
SignedSupportingTokens, thus introducing an assymetry between client and
server policies?

- I found the following issue about usernametoken being always encrypted : 
I tried the correction which was suggested, and this seems to work. But if
there is a good reason for forcing usernametoken encryption, I'd rather know
it before applying such a patch...

In any case, if I read WS-SecurityPolicy 1.2 specs, 5.4.1 UsernameToken
Assertion, it is said :
When the UsernameToken is to be encrypted it SHOULD be listed as a
SignedEncryptedSupportingToken (Section 8.5),
EndorsingEncryptedSupportingToken (Section 8.6) or
SignedEndorsingEncryptedSupportingToken (Section 8.7).

I know it's a "SHOULD" but... even though Axis forces the usernametoken to
be encrypted, shouldn't it support the previous assertions for

I will raise a JIRA issue as soon as possible. Just want to be as precise as
possible about the reasons and consequences in my description :)


Nunny wrote:
> Hi,
>    Can you attach the policy file and the resulting SOAP envelope. The
> issue
> you mentioned about isSecHeaderRequired seems like a bug, please create a
> JIRA for that issue. But at the first glance, it has nothing to do with
> this.
> At the same time, can you try just using the username token as just
> <sp:SignedSupportingTokens/>.
> IIRC, in the asymmetric binding, username tokens are by default encrypted.
> thanks,
> Nandana
> On Thu, Jan 21, 2010 at 12:46 PM, El Bog <> wrote:
>> Hello,
>> I'm trying to build a policy file that would :
>> - use AsymmetricBinding policy,
>> - add the usernametoken to the security header,
>> - Sign and Encrypt that usernametoken.
>> To sign and Encrypt the usernametoken, I've been trying to use the
>> <sp:SignedEncryptedSupportingTokens> assertion.
>> This results in the usernametoken simply not being added to the header...
>> I had a look at the rampart bug archive, and found RAMPART-34 which is
>> very
>> close, however it describes a situation where a <sp:TransportBinding> is
>> used, which is not the case for me.
>> Looking deeper into axis code, I ended looking at the following code :
>> RampartUtil.isSecHeaderRequired method.
>> It seems that this method cheks for :
>> - SupportingTokens,
>> - SignedSupportingTokens,
>> - EndorsingSupportingTokens,
>> - SignedEndorsingSupportingTokens
>> to decide wether a security header is required or not.
>> This results in Rampart considering there is no need for a security
>> header,
>> whereas when I only use a
>> <sp:SignedSupportingTokens> assertion, it does.
>> I do not understand why this method does not check for the others
>> assertions
>> which would also encrypt :
>> - SignedEncryptedSupportingTokens
>> - EncryptedSupportingTokens
>> - EndorsingEncryptedSupportingTokens
>> - SignedEndorsingEncryptedSupportingTokens
>> Am I missing something or is this a bug in Rampart?
>> Regards
>> --
>> View this message in context:
>> Sent from the Axis - User mailing list archive at

View this message in context:
Sent from the Axis - User mailing list archive at

View raw message