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_carpent...@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.
