You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Jesus Areso <ja...@gmail.com> on 2011/09/15 09:25:32 UTC

WS-Security using different outbound and inbound policies

Hi,

I am preparing a client to send a message to a web service. I'm trying to
use rampart to prepare WS-Security layer. I do not know if it is possible to
prepare this scenario with rampart.

My client prepare a message and send it to the service. The body element of
the soap message must signed. The signed info element references of the
signature references to a BinarySecurityToken which it contains the
certificate of the private key that has sign the soap message. Example:

*<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">*
*<soap:Header><wsse:Security soap:mustUnderstand="0" xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:BinarySecurityToken
EncodingType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="CertId-181OO8-BJO58L-TQ7W4U" xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIID8TCCA1qgA....EGdxaZltuEAYgHsw6KUPMty93CHvQeXHHE2Sn8Hxu5E=</wsse:BinarySecurityToken><ds:Signature
Id="Signature-0001" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">*
*<ds:SignedInfo Id="Signature-0001-SignedInfo">*
*<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>*
*<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1
"/>*
*<ds:Reference Id="Signature-0001-Reference-1-LVMI-5A93" URI="#TGSS01">*
*<ds:Transforms>*
*<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>*
*</ds:Transforms>*
*<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>*
*<ds:DigestValue>kQf2oJATwTziUJu9acWqDJE0ZzU=</ds:DigestValue>*
*</ds:Reference>*
*</ds:SignedInfo>*
*<ds:SignatureValue
Id="Signature-0001-SignatureValue">SzZ3nXpQNwytXNWmhCBqwWmSwk5Vsa...iAgtLIq8=</ds:SignatureValue>
*
*<ds:KeyInfo Id="Signature-0001-KeyInfo">*
*<wsse:SecurityTokenReference wsu:Id="STRId-CUMRJC-FN47EW-7VKG53"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Reference
URI="#CertId-181OO8-BJO58L-TQ7W4U" ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
"/></wsse:SecurityTokenReference>*
*</ds:KeyInfo>*
*</ds:Signature></wsse:Security></soap:Header>*
*<soap:Body Id="TGSS01">*
*<RequestMessage xmlns="http://intermediacion.redsara.com
">...</RequestMessage>*
*</soap:Body>*
*</soap:Envelope>*
*
*
The response of the web service is secured with sign and encoding one
element in the response.

*<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">*
*<soap:Header><wsse:Security soap:mustUnderstand="0" xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:BinarySecurityToken
EncodingType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="CertId-181OO8-BJO58L-TQ7W4U" xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIID8TCCA1qgA...vQeXHHE2Sn8Hxu5E=</wsse:BinarySecurityToken><ds:Signature
Id="Signature-0001" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">*
*<ds:SignedInfo Id="Signature-0001-SignedInfo">*
*<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>*
*<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1
"/>*
 *<ds:Reference Id="Signature-0001-Reference-1-LVMI-5A93" URI="#TGSS01">*
*<ds:Transforms>*
*<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>*
*</ds:Transforms>*
*<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>*
*<ds:DigestValue>kQf2oJATwTziUJu9acWqDJE0ZzU=</ds:DigestValue>*
*</ds:Reference>*
*</ds:SignedInfo>*
*<ds:SignatureValue
Id="Signature-0001-SignatureValue">SzZ3nXpQNwytXNWmhCBq...AgtLIq8=</ds:SignatureValue>
*
*<ds:KeyInfo Id="Signature-0001-KeyInfo">*
*<wsse:SecurityTokenReference wsu:Id="STRId-CUMRJC-FN47EW-7VKG53"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Reference
URI="#CertId-181OO8-BJO58L-TQ7W4U" ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
"/></wsse:SecurityTokenReference>*
*</ds:KeyInfo>*
*</ds:Signature><wsse:BinarySecurityToken EncodingType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="CertId-HBJE8B-RY08KW-0TE1O6" xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIIHbjCCBlagAwIBAgIIP...Z5h2vSXXF71Q==</wsse:BinarySecurityToken><xenc:EncryptedKey
Id="EncKeyId-E4SGNA-QJSDQ3"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo xmlns:ds="
http://www.w3.org/2000/09/xmldsig#">*
*<wsse:SecurityTokenReference><wsse:Reference
URI="#CertId-HBJE8B-RY08KW-0TE1O6" ValueType="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
"/></wsse:SecurityTokenReference>*
*</ds:KeyInfo><xenc:CipherData><xenc:CipherValue>DgrP62MFxUR...3uTGJuPif4atTYxU=</xenc:CipherValue></xenc:CipherData><xenc:ReferenceList><xenc:DataReference
URI="#EncDataId-1QMEVK-SLOGV3"/></xenc:ReferenceList></xenc:EncryptedKey></wsse:Security></soap:Header>
*
*<soap:Body Id="TGSS01">*
*<ResponseMessage xmlns="http://intermediacion.redsara.com">*
*<Transmisiones>*
*<TransmisionDatos>*
*<DatosGenericos>...</DatosGenericos>*
*<DatosEspecificos Id="Cifrado0" xmlns="
http://intermediacion.redsara.es/scsp/esquemas/datosespecificos"><xenc:EncryptedData
Id="EncDataId-1QMEVK-SLOGV3" Type="http://www.w3.org/2001/04/xmlenc#Content"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/><ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">*
*<wsse:SecurityTokenReference xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
URI="#EncKeyId-E4SGNA-QJSDQ3"/></wsse:SecurityTokenReference>*
*
</ds:KeyInfo><xenc:CipherData><xenc:CipherValue>hTWAcR7kxqO6w4...JSu+GPSNGEA+lv/9jr</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></DatosEspecificos>
*
 *</TransmisionDatos>*
*</Transmisiones>*
*</ResponseMessage>*
*</soap:Body>*
*</soap:Envelope>*
*
*
As you can see in the response message, soap message has two different
BinarySecurityToken elements, one for the signature and the other one for
the asymmetric encryption (aes128_rsa). This is totally different to the
samples that I have found in the rampart library (basic and policies
folders).

I prepared two policies, one for the outbound message and the other one for
the inbound. In my client I prepare the following lines to assign the
policies:

*String context="/home/apache-tomcat-7.0.20/webapps/axis2/WEB-INF";*
* *
*ConfigurationContext ctx =
ConfigurationContextFactory.createConfigurationContextFromFileSystem(context,
null);*
*CorrientePagoStub cpStub=new CorrientePagoStub(ctx,endPointPruebas);*
*ServiceClient client = cpStub._getServiceClient();*
*client.engageModule("rampart");*
* *
*Options options = new Options();*
*
*
*try {*
* options.setProperty(RampartMessageData.KEY_RAMPART_IN_POLICY,
 loadPolicy(rutaIncomingMessagePolicy));*
*        options.setProperty(RampartMessageData.KEY_RAMPART_OUT_POLICY,
 loadPolicy(rutaOutgoingMessagePolicy));*
* *
*} catch (Exception e1) {*
* // TODO Auto-generated catch block*
* e1.printStackTrace();*
*}*
*options.setTo(new EndpointReference(endPointPruebas));*
*client.setOptions(options);*
*
*
When I send the message (commenting the first setProperty) I receive the
right response, but without decrypt DatosEspecificos element. If the first
setProperty is executed, the same message is obtained (no decrypted and i
suppose sign hasn't been checked) but no errors.

Assuming that I'm following the right way, (if not PLEASE TELL ME!!!) what
should be the structure of the inbound policy?

Thanks for your support.


*
*
*
*

Re: WS-Security using different outbound and inbound policies

Posted by Amila Jayasekara <am...@wso2.com>.
Hi Areso,

Let me first try to understand the context.
Is your service is also secured with Rampart ? and what are the
inbound and outbound security policies applied to service end ?

To my understanding the way, you have configured inbound and outbound
policies are correct. But i didnt completely understand how you
conclude that "sign" has not been checked in incoming message policy.

According to your description the inbound message policy should
contain an asymmetric binding, possibly with a <Body> sign element.

<wsp:Policy wsu:Id="UserNameToken"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    <wsp:ExactlyOne>
        <wsp:All>
        <sp:AsymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
          <wsp:Policy>
            <sp:InitiatorToken>
              <wsp:Policy>
                <sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
                  <wsp:Policy>
....
....
....

 <sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
          <sp:Body/>
        </sp:SignedParts>
....
....
</wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

Thanks
AmilaJ

On Thu, Sep 15, 2011 at 3:25 AM, Jesus Areso <ja...@gmail.com> wrote:
> Hi,
> I am preparing a client to send a message to a web service. I'm trying to
> use rampart to prepare WS-Security layer. I do not know if it is possible to
> prepare this scenario with rampart.
> My client prepare a message and send it to the service. The body element of
> the soap message must signed. The signed info element references of the
> signature references to a BinarySecurityToken which it contains the
> certificate of the private key that has sign the soap message. Example:
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header><wsse:Security soap:mustUnderstand="0"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:BinarySecurityToken
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
> wsu:Id="CertId-181OO8-BJO58L-TQ7W4U"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIID8TCCA1qgA....EGdxaZltuEAYgHsw6KUPMty93CHvQeXHHE2Sn8Hxu5E=</wsse:BinarySecurityToken><ds:Signature
> Id="Signature-0001" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo Id="Signature-0001-SignedInfo">
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> <ds:Reference Id="Signature-0001-Reference-1-LVMI-5A93" URI="#TGSS01">
> <ds:Transforms>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>kQf2oJATwTziUJu9acWqDJE0ZzU=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue
> Id="Signature-0001-SignatureValue">SzZ3nXpQNwytXNWmhCBqwWmSwk5Vsa...iAgtLIq8=</ds:SignatureValue>
> <ds:KeyInfo Id="Signature-0001-KeyInfo">
> <wsse:SecurityTokenReference wsu:Id="STRId-CUMRJC-FN47EW-7VKG53"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Reference
> URI="#CertId-181OO8-BJO58L-TQ7W4U"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/></wsse:SecurityTokenReference>
> </ds:KeyInfo>
> </ds:Signature></wsse:Security></soap:Header>
> <soap:Body Id="TGSS01">
> <RequestMessage
> xmlns="http://intermediacion.redsara.com">...</RequestMessage>
> </soap:Body>
> </soap:Envelope>
> The response of the web service is secured with sign and encoding one
> element in the response.
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header><wsse:Security soap:mustUnderstand="0"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:BinarySecurityToken
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
> wsu:Id="CertId-181OO8-BJO58L-TQ7W4U"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIID8TCCA1qgA...vQeXHHE2Sn8Hxu5E=</wsse:BinarySecurityToken><ds:Signature
> Id="Signature-0001" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo Id="Signature-0001-SignedInfo">
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> <ds:Reference Id="Signature-0001-Reference-1-LVMI-5A93" URI="#TGSS01">
> <ds:Transforms>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>kQf2oJATwTziUJu9acWqDJE0ZzU=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue
> Id="Signature-0001-SignatureValue">SzZ3nXpQNwytXNWmhCBq...AgtLIq8=</ds:SignatureValue>
> <ds:KeyInfo Id="Signature-0001-KeyInfo">
> <wsse:SecurityTokenReference wsu:Id="STRId-CUMRJC-FN47EW-7VKG53"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Reference
> URI="#CertId-181OO8-BJO58L-TQ7W4U"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/></wsse:SecurityTokenReference>
> </ds:KeyInfo>
> </ds:Signature><wsse:BinarySecurityToken
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
> wsu:Id="CertId-HBJE8B-RY08KW-0TE1O6"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIIHbjCCBlagAwIBAgIIP...Z5h2vSXXF71Q==</wsse:BinarySecurityToken><xenc:EncryptedKey
> Id="EncKeyId-E4SGNA-QJSDQ3"
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <wsse:SecurityTokenReference><wsse:Reference
> URI="#CertId-HBJE8B-RY08KW-0TE1O6"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/></wsse:SecurityTokenReference>
> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>DgrP62MFxUR...3uTGJuPif4atTYxU=</xenc:CipherValue></xenc:CipherData><xenc:ReferenceList><xenc:DataReference
> URI="#EncDataId-1QMEVK-SLOGV3"/></xenc:ReferenceList></xenc:EncryptedKey></wsse:Security></soap:Header>
> <soap:Body Id="TGSS01">
> <ResponseMessage xmlns="http://intermediacion.redsara.com">
> <Transmisiones>
> <TransmisionDatos>
> <DatosGenericos>...</DatosGenericos>
> <DatosEspecificos Id="Cifrado0"
> xmlns="http://intermediacion.redsara.es/scsp/esquemas/datosespecificos"><xenc:EncryptedData
> Id="EncDataId-1QMEVK-SLOGV3" Type="http://www.w3.org/2001/04/xmlenc#Content"
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/><ds:KeyInfo
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <wsse:SecurityTokenReference
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
> URI="#EncKeyId-E4SGNA-QJSDQ3"/></wsse:SecurityTokenReference>
> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>hTWAcR7kxqO6w4...JSu+GPSNGEA+lv/9jr</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></DatosEspecificos>
> </TransmisionDatos>
> </Transmisiones>
> </ResponseMessage>
> </soap:Body>
> </soap:Envelope>
> As you can see in the response message, soap message has two different
> BinarySecurityToken elements, one for the signature and the other one for
> the asymmetric encryption (aes128_rsa). This is totally different to the
> samples that I have found in the rampart library (basic and policies
> folders).
> I prepared two policies, one for the outbound message and the other one for
> the inbound. In my client I prepare the following lines to assign the
> policies:
> String context="/home/apache-tomcat-7.0.20/webapps/axis2/WEB-INF";
> ConfigurationContext ctx =
> ConfigurationContextFactory.createConfigurationContextFromFileSystem(context,
> null);
> CorrientePagoStub cpStub=new CorrientePagoStub(ctx,endPointPruebas);
> ServiceClient client = cpStub._getServiceClient();
> client.engageModule("rampart");
> Options options = new Options();
> try {
> options.setProperty(RampartMessageData.KEY_RAMPART_IN_POLICY,
>  loadPolicy(rutaIncomingMessagePolicy));
>         options.setProperty(RampartMessageData.KEY_RAMPART_OUT_POLICY,
>  loadPolicy(rutaOutgoingMessagePolicy));
> } catch (Exception e1) {
> // TODO Auto-generated catch block
> e1.printStackTrace();
> }
> options.setTo(new EndpointReference(endPointPruebas));
> client.setOptions(options);
> When I send the message (commenting the first setProperty) I receive the
> right response, but without decrypt DatosEspecificos element. If the first
> setProperty is executed, the same message is obtained (no decrypted and i
> suppose sign hasn't been checked) but no errors.
> Assuming that I'm following the right way, (if not PLEASE TELL ME!!!) what
> should be the structure of the inbound policy?
> Thanks for your support.
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org