Responses below marked with [mdoughty]:
-Original Message-
From: uthaiyashan...@gmail.com [mailto:uthaiyashan...@gmail.com] On Behalf Of
Uthaiyashankar
Sent: Wednesday, July 29, 2009 1:50 AM
To: Apache AXIS C User List
Subject: Re: Applying Nonce and Created to "PasswordText" UsernameToken and
then Encrypting UsernameToken
On Wed, Jul 29, 2009 at 6:29 AM, Doughty,
Michael wrote:
> I am attempting to use Axis2/C with Rampart/C to talk to a Web service which
> requires the following to be done on input:
>
>
>
> (1) Include a UsernameToken in PasswordText encoding. Even though it is
> in PasswordText, the WS requires that a Nonce element be passed in with a
> unique value and a Created element be passed in with a value within five
> minutes.
This needs to be implemented in Rampart/C. Since "Nonce" and "Created"
are optional, Rampart/C omits it in the case of plain text password.
But, according to the spec, it is RECOMMENDED to include them, so we
should implement it.
Could you tell which service you are trying to consume? .NET,
Axis2/Java and most of the other frameworks normally don't need these
elements in the case of plain text passwords.
[mdoughty] It is actually a set of Web services used internally and with a few
customers. They are written on the TIBCO ActiveMatrix framework. We
implemented it this way because we want to try to prevent replay attacks as
strongly as possible, so we require Nonce and Created to be passed in, as well
as the UsernameToken to be encrypted.
[mdoughty] We can turn the policy requirement off on the policy agent doing the
enforcement, but this of course would apply to any clients using those
services. Still, given that Axis2/C and Rampart/C are such widely used tools,
I believe that the better option for our purposes would be to modify the policy
code itself to treat Nonce and Created as optional when used with PasswordText
encoding. In that scenario we would validate one or both only if they are
passed in. This would sort of put the onus on clients though to decide what
level of protection against replay attacks they want.
[mdoughty] In any case, this is good information and I appreciate you taking
time to answer. I definitely hope Rampart/C implements this option in the
future, but I think for now we will do what we can to make due without it.
>
> (2) The Web service then requires that the UsernameToken be encrypted at
> the element level. The SOAP:Body must also be encrypted using the same
> public server certificate at the content level.
This can be done by including following xml snippet in the policy file.
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
/>
However, according to WS-SecurityPolicy Specification, including
"UsernameToken" in EncryptedParts is wrong. We should fix it properly
in Rampart/C.
[mdoughty] Oh wow, thanks for that information. Being able to encrypt
UsernameToken is actually much more important to us than including Nonce and
Created.
Regards,
Shankar
>
>
>
> I have been able to accomplish this using Axis2/Rampart combination for Java
> (though only by using the older method), but I haven't been able to find
> options to do the same for Axis2/C / Rampart/C combo. Is it at all possible
> to do this?
--
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"
