axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From El Bog <seb_carpent...@yahoo.fr>
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) :
http://old.nabble.com/file/p27259940/policy.username_pwd_encrypted.xml
policy.username_pwd_encrypted.xml 
And here is an extract of the message sent that I monitored with tcpmon :
(body removed because irrelevant and confidential)
http://old.nabble.com/file/p27259940/sent.username_pwd_encrypted.txt
sent.username_pwd_encrypted.txt 

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 :
http://old.nabble.com/file/p27259940/sent.username_pwd.txt
sent.username_pwd.txt 

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

in MessageBuilder.build :

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

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 :
http://issues.apache.org/jira/browse/RAMPART-225
http://issues.apache.org/jira/browse/RAMPART-225 
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
usernametoken?

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 :)

Regards


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 <seb_carpentier@yahoo.fr> 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:
>> http://old.nabble.com/-Axis2-1.4.1---Rampart-1.4--AsymmetricBinding-and-SignedEncryptedSupportingTokens-policy-not-appied-on-Usernametoken-tp27256538p27256538.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/-Axis2-1.4.1---Rampart-1.4--AsymmetricBinding-and-SignedEncryptedSupportingTokens-policy-not-appied-on-Usernametoken-tp27256538p27259940.html
Sent from the Axis - User mailing list archive at Nabble.com.


Mime
View raw message