Re: Applying Nonce and Created to "PasswordText" UsernameToken and then Encrypting UsernameToken

[Uthaiyashankar <sh...@wso2.com>]

On Wed, Jul 29, 2009 at 6:29 AM, Doughty,
Michael<Mi...@bmc.com> 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.


>
> (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.

<sp:EncryptedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
    <sp:Body />
    <sp:Header Name="UsernameToken"
Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
/>
</sp:EncryptedParts>

However, according to WS-SecurityPolicy Specification, including
"UsernameToken" in EncryptedParts is wrong. We should fix it properly
in Rampart/C.

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"

RE: Applying Nonce and Created to "PasswordText" UsernameToken and then Encrypting UsernameToken

["Doughty, Michael" <Mi...@bmc.com>]

Responses below marked with [mdoughty]:

-----Original Message-----
From: uthaiyashankar@gmail.com [mailto:uthaiyashankar@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<Mi...@bmc.com> 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.

<sp:EncryptedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
    <sp:Body />
    <sp:Header Name="UsernameToken"
Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
/>
</sp:EncryptedParts>

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"