You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by El Bog <se...@yahoo.fr> on 2010/01/21 12:46:39 UTC
[Axis2 1.4.1 / Rampart 1.4] AsymmetricBinding and
SignedEncryptedSupportingTokens policy not appied on Usernametoken
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.
Re: [Axis2 1.4.1 / Rampart 1.4] AsymmetricBinding and
SignedEncryptedSupportingTokens policy not appied on Usernametoken
Posted by El Bog <se...@yahoo.fr>.
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 <se...@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.
Re: [Axis2 1.4.1 / Rampart 1.4] AsymmetricBinding and
SignedEncryptedSupportingTokens policy not appied on Usernametoken
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <se...@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.
>
>