Hi,
The sending side this should work, but the problem is in the response.
Sandesha uses a separate sender in both client and server side as a way
around to the axis's pure synchronous behavior.
If you want to do the above, configure only the WSDoAllSender in the server
side sender's OUT path and also WSDoAllReceiver in the client side
listener's IN path as I have mentioned.
Let us know the results.
Thanks,
Jaliya
----- Original Message -----
From: "Benjamin Schmeling" <[EMAIL PROTECTED]>
To: "Jaliya Ekanayake" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Saturday, May 20, 2006 11:41 AM
Subject: Re: WSS4J+ Sandesha1.0
Hi,
For reliable messaging (RM) we need to add some additional headers to the
SOAP message. So there is no way that we encrypt the SOAP message and then
use RM.
I have this sequence message whereas all other RM messages are plain
messages. I do not understand why there is no way to get this running.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing";>
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
<xenc:EncryptedKey>
<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>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=dims</ds:X509IssuerName>
<ds:X509SerialNumber>44369778256217224370984914847992022613</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>gIeQYqGix2z+3BCxRNM42kIp9x3Nn8YEBG7AJ0MRCD3WoGOW/R4XXTHHdk0FdhKG+SQQTVwZ4rwUGv4mIs4qhQ==</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#EncDataId-25420041"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
</wsse:Security>
<wsa:MessageID
soapenv:mustUnderstand="1">uuid:c53adc90-e814-11da-a5f1-cea64a64d378</wsa:MessageID>
<wsa:To
soapenv:mustUnderstand="1">http://localhost:8080/axis/services/SimpleFlightServiceRS</wsa:To>
<wsa:Action
soapenv:mustUnderstand="1">urn:wsrm:SimpleFlightServiceRS</wsa:Action>
<wsa:From soapenv:mustUnderstand="1">
<wsa:Address>http://192.168.2.28:9090/axis/services/RMService</wsa:Address>
</wsa:From>
<wsa:ReplyTo soapenv:mustUnderstand="1">
<wsa:Address>http://192.168.2.28:9090/axis/services/RMService</wsa:Address>
</wsa:ReplyTo>
<wsrm:Sequence soapenv:mustUnderstand="1"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm";>
<wsrm:Identifier>uuid:c6836220-e814-11da-a5f1-cea64a64d378</wsrm:Identifier>
<wsrm:MessageNumber>1</wsrm:MessageNumber>
<wsrm:LastMessage/>
</wsrm:Sequence>
</soapenv:Header>
<soapenv:Body>
<xenc:EncryptedData Id="EncDataId-25420041"
Type="http://www.w3.org/2001/04/xmlenc#Content";>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>HqPw4hsKXhGgKpE4Z5O7Szmnmdk5Vj9S5rDI1RJo02cck84FvYFfQEWxydzGpfd3WyIz8JOUswMrB6khXR84iP6xeMceXYY4mnA5p20SRwBG+5mBJVz8Eyr2sQSYBrpILGcvXIxNPWTZ0aU4r7J+uEKXj+zHAtSkUL8VxWV+VywpawL+eTXT9Kn3Z541ukk0eLeQR5GwRc5rOLxnCZcq5eKcJu1oYXQJVa+3Lw3Jpcn8ULCmqrZI0AVVfKfZ5U7b0V4w7+fmc8/WkoUk0NfWG1xFcn+NuhLiZw9XunzVBtsXKPO24ZFOuJkYqOR7L9OEeY+97vzlq/YAy1lbXlqxfeKQ9cjYbI5eAQL1En6FpVaZqsQ7TeIWxeNSZvgqyAbCzJ9FIkac7WB0btDQbujYgiCgesJi1MzB74gRDILMUNd0TSjFUxqGrbycZbb5dT8dZrl85yKS95XAMb2LBSsPBJgDXC9vfYLyUXobKyaxxKaQWnT73WttOB/4GEhoEFTNSjIR9h7RPhWxjyAyUuQes89hrsLvfjwAT7FYPO09HtnNToJAa5tEW1f8FSpgu8iPJfcLdjdxjd+Dzz2u8TGEDRic1BuVUIrvXoaRNHV41IOzxLzp8sgq6SDMZAWozEIDWS8HGwu4MfEh1eVqIL4vSmopcFWl+BeGBWl0y0Gn1WbP4nu4ZqD1ePkP4dgQInV/jPYFaXc0SW7oHKn9ExrI0MjRuqvwGkyDU5xMMY/piDPkyQaKqRND1mYdzmTPhgg0tnBhsxUunvwZrgXN88YUIArM7u6gNO4Xo1Y3XghIuZg0bAR1qtMovIDyt+gXW0pxvCUuvydIPYreAXPXbmlvGj1WUZyE6TuJB+3qeEHkxFIwzOdWDDHd1a9tmUYBe9SHa6KmWxid40MkaZhWVSIOT4ggwwiwQIDKpWEHy3V54ABPJ1ybnejM6X0CSw2roSdLp8v5/Cx62FJS
ciVZzIpAddP+nAmuufD2ET8g8qKBTH0w1GwdJrd+NDRMbJsPn5ZXVbLDmIlJmClkucW8jVYT56IR6ZravEV5V7ISM14mxQzn0yhxeZeASz1f37ZKFruwyuV9yoKjCv2FoIPVZ2J1d2hQjWDN8RpLf9qiO9SyarNg8CLMIGgdj44ephbjuUL2oPYn4wkcRFKL04gFZxYHuc7OqshlFd1lo9ioUqx9IIsdkUX0HPSeS0ELAXBtbG9t7mOBql+r/Jqdz+KxrQLhk4kDJDpVdNtpsDu8SDsr0nBpm0jsacsLANI0pCq2NkGBwBvd/KKyKxVbJmep9piNno/SOTrfspM4N7aZJzOhefkPMaeyIwClRwBNE9QBH1mPENLUeSvNq3icTEJQV9R+6wTnPMXtgar1MoCOvHRSs1atjZg4emzBtQZQKlWvGyWD35U1ff3WgzGBLTPiYaADNtOFlEDwjH2LW9Dm770c4HRTTXpN5+zQ9SLXgPIpU3bbe4DH+hTqGixdnPGq+sNjiU+gmNLkVtFmbiDI303jnbEY0IdRfaeofdMC677xGz0XIjHY/T+jg6Gbjzv8vWJa+5Z30eNB7EzrMu5VnMFR7qfE41Sq20G2R4bWFWPymKa7eQrN9xIAgY+sNsaEFtpzyytvS4EqoVUL5oDJ2RKe9kxmO5Vz6UR7I4nPww6LFrEj4KIA+EEv9kIriCP8NzKnYXEZOqvd6omsnwZiU8weIiLWZaevUxTJkI/ZSlTy/GWm+KLXJdpT6uR2NEjry3RZdEk9Vjvrs2HJ2SI1uPY+qcOxI0IlZbHEzd2Fp7dJ1aa5N87EN3q7OUuF4Tz6dfW4tw==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
The intended use of RM and Security is to use Security to encrypt messages
after RM. Of course we can customize both handlers (RM and Security)
according to the way you want by modifying the handlers.
This means that you have to encrypt all RM messages completely. This
would be very time consuming.
Maybe we could tell the Security Handler not to process the unsecured RM
message by using SOAP's actor attribute?
Here is the way how you can configure Sandesha and WSS4J according to the
specifications.
In the client side WSDoAllSender should be present in the
"sandesha.properties" file not in the client-config.wsdd as shown in the
sandesha.properties.
# If there are additional handlers that needs to be included in the Client
side Senders OUT path
# then use the following configuration.
#ClientOUTHandler1 = org.apache.ws.axis.security.WSDoAllSender
#ClientOUTHandler1Param1 = name:value
#ClientOUTHandler1Param2 = name:value
WSDoAllReceiver should be configured the same way for client side
listner's IN path.
# These are the handlers for the Listener's IN path. Listener's IN path is
used to
# retrieve asynchronous responses and other RM protocol messages and hence
the handlers we put here
# should be the RESPONSE handlers with respect to normal invocation.
#ListenerINHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
#ListenerINHandler1Param1 = name:value
#ListenerINHandler1Param2 = name:value
In the server side we need WSDoAllReceiver present in the
server-config.wsdd as you have specified below. In addition we need
WSDoAllSender to be configured for server side sender using the
sandesha.properties file.
#Configure handlers for the OUT path of the server side sender.
#ServerOUTHandler1 = org.apache.ws.axis.security.WSDoAllSender
#ServerOUTHandler1Param1 = param1:BBBB
#ServerOUTHandler1Param2 = param2:CCCC
That is it and it should work. We have tested this for interops as well.
The simple rule is Security handler's should be present after all the
other handlers and that is why we need to configure them using special
mechanism.
Thanks,
Jaliya
----- Original Message ----- From: "Benjamin Schmeling"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, May 20, 2006 5:12 AM
Subject: WSS4J+ Sandesha1.0
Hi,
I have a target Web Service that has a security and a reliable messaging
handler:
<service name="SimpleFlightServiceRS" provider="Handler">
<requestFlow>
<handler type="java:org.apache.ws.axis.security.WSDoAllReceiver">
<parameter name="action" value="Encrypt" />
<parameter name="decryptionPropFile" value="crypto.properties"
/>
<parameter name="passwordCallbackClass"
value="de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler"
/>
</handler>
<handler
type="java:org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler"/>
<handler
type="java:org.apache.axis.message.addressing.handler.AddressingHandler"/>
</requestFlow>
My client processes a given encrypted SOAP message and sends it with
Sandesha. The sequence message containing the application data has
security headers and encrypted content. When Sandesha sends the
CreateSequence message it has no Security Headers, so the WSDoAllReceiver
does not accept this message. I think it is not necessary to encrypt the
CreateSequence, CreateSequenceResponse, Acknowledge and TerminateSequence
message. Is it possible to get this working, so the WSDoAllReceiver
accepts the messages without security headers and how should I configure
my target service and client?
Thanks,
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
