You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Benjamin Schmeling <Be...@gmx.de> on 2006/05/20 11:12:25 UTC
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Yes, we should correct it as follows
# If there are additional handlers that needs to be included in the Senders
request path
# then use the following configuration.
# requestHandler1 = package.name.DummyHandler
requestHandler1 = org.apache.ws.axis.security.WSDoAllSender
# These are the handlers for the Listener's request path. Listener's request
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.
listenerRequestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
listenerRequestHandler2 =
org.apache.axis.message.addressing.handler.AddressingHandler
listenerRequestHandler3 =
org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
Thanks,
Jaliya
----- Original Message -----
From: "Benjamin Schmeling" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Sent: Tuesday, May 30, 2006 2:39 PM
Subject: Re: WSS4J+ Sandesha1.0
Yes I think they are right see attachement. Maybe the
sandesha.properties of my service (SandeshaClientService) is wrong?
This is the properties file of my client:
CLIENT_LISTENER_PORT = 9090
SIMPLE_AXIS_SERVER_PORT = 8080
responseHandler1 =
org.apache.axis.message.addressing.handler.AddressingHandler
responseHandler2 = org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
listenerRequestHandler1 =
org.apache.axis.message.addressing.handler.AddressingHandler
listenerRequestHandler2 =
org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
> Did you set the required parameters correctly for the WSDoAllSender
> and WSDoAllReceiver.
> I did not correct them in my mail, and just swapped the names
>
> - Jaliya
>
> ----- Original Message ----- From: "Benjamin Schmeling"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Sent: Tuesday, May 30, 2006 2:05 PM
> Subject: Re: WSS4J+ Sandesha1.0
>
>
> Hi,
>
> thanks for your help, but for now with your property file and the
> WSDoAllSender in the request and response path there is no message from
> the SandeshaClientService visible in the TCPMonitor but the following
> error:
>
> 30 Mai 2006 19:41:20,770 ERROR - WSDoAllSender: No action defined
>> Hi,
>>
>> Please see my comments below.
>>
>> Thanks,
>> - Jaliya
>> ----- Original Message ----- From: "Benjamin Schmeling"
>> <Be...@gmx.de>
>> To: "Jaliya Ekanayake" <ja...@apache.org>
>> Cc: <sa...@ws.apache.org>
>> Sent: Tuesday, May 30, 2006 4:30 AM
>> Subject: Re: WSS4J+ Sandesha1.0
>>
>>
>> Hi,
>>
>> I did this like you said, the result is that the target Web Service
>> throws a fault:" Did not understand "MustUnderstand"
>> header(s)"
>>
>> This happens because the message contains some headers with
>> MustUnderstand =true but there is no handler to interpret the
>> MustUnderstand Header.
>>
>> I do not understand why I should put "WSDoAllSender in the server side
>> sender's OUT path ".
>>
>> Sandesha and WSS4J provide two QoSs and they don't have any
>> dependency between them. So if we need both reliable messaging and
>> security we need to configure both in the correct order.
>>
>> Say you need only the security, then what will be your configuration.
>> We need WSDoAllReceiver in the Web Services request path and the
>> WSDoAllSender in the Service's response path.
>>
>> In Sandesha we cannot use the normal response path of axis because
>> according to the RM specification request and response should be in
>> two sequences. So we use a separate sender for sending in both client
>> side and server side.
>>
>> Now when we combine both Sandesha and WSS4J we need to arrange the
>> handlers as I have explained earlier.
>>
>>
>> The problem at the moment is that the target
>> service does not understand the security headers because there is no
>> security handler defined for it but only a RMServerRequestHandler. This
>> Handler should get affected from the changes in the sandesha.properties
>> ? And it should decrypt my message?
>>
>> RMServerRequestHandler will not perform any security related
>> processing. So you need to configure WSDoAllReciver before this
>> handler to do the decryption.
>>
>> But if so would it not decline the
>> StartSequence message that is without a Security header (like it was the
>> case when I defined it directly as a request handler)?
>>
>> As long as the RM headers are not encrypted Sandesha handlers should
>> work. The must understand fault is generated from axis because of the
>> reason I have mentioned above.
>>
>> I attached my
>> servers sandesha.properties file.
>>
>> Oops, seems like you have changed the sender and receiver, check the
>> attached file.
>> In addition to the above you need to configure WSDoAllReciver in the
>> server-config.wsdd before the addressing and RM handlers in the
>> request path. (this was correctly done in your previous mail)
>>
>>
>> Thanks,
>>
>> Benjamin
>>
>>
>>> 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"
>>> <Be...@gmx.de>
>>> To: "Jaliya Ekanayake" <ja...@apache.org>
>>> Cc: <sa...@ws.apache.org>
>>> 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/Cx6
2
>>>
> FJS
>>>
>>> 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"
>>>> <Be...@gmx.de>
>>>> To: <sa...@ws.apache.org>
>>>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>>> # This is the port in which client side listener listens.
>>> CLIENT_LISTENER_PORT = 9090
>>>
>>> # This is the SimpleAxisServerImpl running port. Only for testing
>>> purposes.
>>> SIMPLE_AXIS_SERVER_PORT = 8080
>>>
>>> # Any number of handlers can be included as shown below for the
>>> response path of the Sender.
>>>
>>> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>> responseHandler1 =
>>> org.apache.axis.message.addressing.handler.AddressingHandler
>>> responseHandler2 =
>>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>>
>>>
>>> # If there are additional handlers that needs to be included in the
>>> Senders request path
>>> # then use the following configuration.
>>> # requestHandler1 = package.name.DummyHandler
>>>
>>> #requestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>>
>>> # These are the handlers for the Listener's request path. Listener's
>>> request 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.
>>>
>>>
>>> listenerRequestHandler1 =
>>> org.apache.axis.message.addressing.handler.AddressingHandler
>>> listenerRequestHandler2 =
>>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>> #listenerRequestHandler3 = org.apache.ws.axis.security.WSDoAllReceiver
>>>
>>> # Define the strategy for executing web service invokes.
>>> # This impl uses the apache axis thread pool and configures
>>> # it to the given size.
>>> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>>>
>>>
>>> # Define the invoke handler that will execute the web service invokes.
>>> # This impl simply delegates to the handler specified by the
>>> "invoker" param.
>>> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>>>
>>>
>>> # 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.
>>>
>>> #ServerINHandler1 = org.apache.ws.axis.security.WSDoAllSender
>>> #ServerINHandler1Param1 = action:Encrypt
>>> #ServerINHandler1Param2 = decryptionPropFile:crypto.properties
>>> #ServerINHandler1Param3 =
>>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>>
>>>
>>> #Configure handlers for the OUT path of the server side sender.
>>> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>> ListenerOUTHandler1Param1 = action:Encrypt
>>> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
>>> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
>>> ListenerOUTHandler1Param4 =
>>> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
>>> ListenerOUTHandler1Param5 =
>>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
># This is the port in which client side listener listens.
> CLIENT_LISTENER_PORT = 9090
>
> # This is the SimpleAxisServerImpl running port. Only for testing
> purposes.
> SIMPLE_AXIS_SERVER_PORT = 8080
>
> # Any number of handlers can be included as shown below for the response
> path of the Sender.
>
> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> responseHandler1 =
> org.apache.axis.message.addressing.handler.AddressingHandler
> responseHandler2 =
> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>
>
> # If there are additional handlers that needs to be included in the
> Senders request path
> # then use the following configuration.
> # requestHandler1 = package.name.DummyHandler
>
> requestHandler1 = org.apache.ws.axis.security.WSDoAllSender
>
> # These are the handlers for the Listener's request path. Listener's
> request 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.
>
> listenerRequestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> listenerRequestHandler2 =
> org.apache.axis.message.addressing.handler.AddressingHandler
> listenerRequestHandler3 =
> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>
>
> # Define the strategy for executing web service invokes.
> # This impl uses the apache axis thread pool and configures
> # it to the given size.
> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>
> # Define the invoke handler that will execute the web service invokes.
> # This impl simply delegates to the handler specified by the "invoker"
> param.
> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>
> # 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.
>
> ServerINHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> ServerINHandler1Param1 = action:Encrypt
> ServerINHandler1Param2 = decryptionPropFile:crypto.properties
> ServerINHandler1Param3 =
> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>
> #Configure handlers for the OUT path of the server side sender.
> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllSender
> ListenerOUTHandler1Param1 = action:Encrypt
> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
> ListenerOUTHandler1Param4 =
> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
> ListenerOUTHandler1Param5 =
> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Yes, we should correct it as follows
# If there are additional handlers that needs to be included in the Senders
request path
# then use the following configuration.
# requestHandler1 = package.name.DummyHandler
requestHandler1 = org.apache.ws.axis.security.WSDoAllSender
# These are the handlers for the Listener's request path. Listener's request
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.
listenerRequestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
listenerRequestHandler2 =
org.apache.axis.message.addressing.handler.AddressingHandler
listenerRequestHandler3 =
org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
Thanks,
Jaliya
----- Original Message -----
From: "Benjamin Schmeling" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Sent: Tuesday, May 30, 2006 2:39 PM
Subject: Re: WSS4J+ Sandesha1.0
Yes I think they are right see attachement. Maybe the
sandesha.properties of my service (SandeshaClientService) is wrong?
This is the properties file of my client:
CLIENT_LISTENER_PORT = 9090
SIMPLE_AXIS_SERVER_PORT = 8080
responseHandler1 =
org.apache.axis.message.addressing.handler.AddressingHandler
responseHandler2 = org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
listenerRequestHandler1 =
org.apache.axis.message.addressing.handler.AddressingHandler
listenerRequestHandler2 =
org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
> Did you set the required parameters correctly for the WSDoAllSender
> and WSDoAllReceiver.
> I did not correct them in my mail, and just swapped the names
>
> - Jaliya
>
> ----- Original Message ----- From: "Benjamin Schmeling"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Sent: Tuesday, May 30, 2006 2:05 PM
> Subject: Re: WSS4J+ Sandesha1.0
>
>
> Hi,
>
> thanks for your help, but for now with your property file and the
> WSDoAllSender in the request and response path there is no message from
> the SandeshaClientService visible in the TCPMonitor but the following
> error:
>
> 30 Mai 2006 19:41:20,770 ERROR - WSDoAllSender: No action defined
>> Hi,
>>
>> Please see my comments below.
>>
>> Thanks,
>> - Jaliya
>> ----- Original Message ----- From: "Benjamin Schmeling"
>> <Be...@gmx.de>
>> To: "Jaliya Ekanayake" <ja...@apache.org>
>> Cc: <sa...@ws.apache.org>
>> Sent: Tuesday, May 30, 2006 4:30 AM
>> Subject: Re: WSS4J+ Sandesha1.0
>>
>>
>> Hi,
>>
>> I did this like you said, the result is that the target Web Service
>> throws a fault:" Did not understand "MustUnderstand"
>> header(s)"
>>
>> This happens because the message contains some headers with
>> MustUnderstand =true but there is no handler to interpret the
>> MustUnderstand Header.
>>
>> I do not understand why I should put "WSDoAllSender in the server side
>> sender's OUT path ".
>>
>> Sandesha and WSS4J provide two QoSs and they don't have any
>> dependency between them. So if we need both reliable messaging and
>> security we need to configure both in the correct order.
>>
>> Say you need only the security, then what will be your configuration.
>> We need WSDoAllReceiver in the Web Services request path and the
>> WSDoAllSender in the Service's response path.
>>
>> In Sandesha we cannot use the normal response path of axis because
>> according to the RM specification request and response should be in
>> two sequences. So we use a separate sender for sending in both client
>> side and server side.
>>
>> Now when we combine both Sandesha and WSS4J we need to arrange the
>> handlers as I have explained earlier.
>>
>>
>> The problem at the moment is that the target
>> service does not understand the security headers because there is no
>> security handler defined for it but only a RMServerRequestHandler. This
>> Handler should get affected from the changes in the sandesha.properties
>> ? And it should decrypt my message?
>>
>> RMServerRequestHandler will not perform any security related
>> processing. So you need to configure WSDoAllReciver before this
>> handler to do the decryption.
>>
>> But if so would it not decline the
>> StartSequence message that is without a Security header (like it was the
>> case when I defined it directly as a request handler)?
>>
>> As long as the RM headers are not encrypted Sandesha handlers should
>> work. The must understand fault is generated from axis because of the
>> reason I have mentioned above.
>>
>> I attached my
>> servers sandesha.properties file.
>>
>> Oops, seems like you have changed the sender and receiver, check the
>> attached file.
>> In addition to the above you need to configure WSDoAllReciver in the
>> server-config.wsdd before the addressing and RM handlers in the
>> request path. (this was correctly done in your previous mail)
>>
>>
>> Thanks,
>>
>> Benjamin
>>
>>
>>> 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"
>>> <Be...@gmx.de>
>>> To: "Jaliya Ekanayake" <ja...@apache.org>
>>> Cc: <sa...@ws.apache.org>
>>> 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/Cx6
2
>>>
> FJS
>>>
>>> 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"
>>>> <Be...@gmx.de>
>>>> To: <sa...@ws.apache.org>
>>>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>>> # This is the port in which client side listener listens.
>>> CLIENT_LISTENER_PORT = 9090
>>>
>>> # This is the SimpleAxisServerImpl running port. Only for testing
>>> purposes.
>>> SIMPLE_AXIS_SERVER_PORT = 8080
>>>
>>> # Any number of handlers can be included as shown below for the
>>> response path of the Sender.
>>>
>>> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>> responseHandler1 =
>>> org.apache.axis.message.addressing.handler.AddressingHandler
>>> responseHandler2 =
>>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>>
>>>
>>> # If there are additional handlers that needs to be included in the
>>> Senders request path
>>> # then use the following configuration.
>>> # requestHandler1 = package.name.DummyHandler
>>>
>>> #requestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>>
>>> # These are the handlers for the Listener's request path. Listener's
>>> request 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.
>>>
>>>
>>> listenerRequestHandler1 =
>>> org.apache.axis.message.addressing.handler.AddressingHandler
>>> listenerRequestHandler2 =
>>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>> #listenerRequestHandler3 = org.apache.ws.axis.security.WSDoAllReceiver
>>>
>>> # Define the strategy for executing web service invokes.
>>> # This impl uses the apache axis thread pool and configures
>>> # it to the given size.
>>> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>>>
>>>
>>> # Define the invoke handler that will execute the web service invokes.
>>> # This impl simply delegates to the handler specified by the
>>> "invoker" param.
>>> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>>>
>>>
>>> # 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.
>>>
>>> #ServerINHandler1 = org.apache.ws.axis.security.WSDoAllSender
>>> #ServerINHandler1Param1 = action:Encrypt
>>> #ServerINHandler1Param2 = decryptionPropFile:crypto.properties
>>> #ServerINHandler1Param3 =
>>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>>
>>>
>>> #Configure handlers for the OUT path of the server side sender.
>>> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>> ListenerOUTHandler1Param1 = action:Encrypt
>>> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
>>> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
>>> ListenerOUTHandler1Param4 =
>>> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
>>> ListenerOUTHandler1Param5 =
>>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
># This is the port in which client side listener listens.
> CLIENT_LISTENER_PORT = 9090
>
> # This is the SimpleAxisServerImpl running port. Only for testing
> purposes.
> SIMPLE_AXIS_SERVER_PORT = 8080
>
> # Any number of handlers can be included as shown below for the response
> path of the Sender.
>
> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> responseHandler1 =
> org.apache.axis.message.addressing.handler.AddressingHandler
> responseHandler2 =
> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>
>
> # If there are additional handlers that needs to be included in the
> Senders request path
> # then use the following configuration.
> # requestHandler1 = package.name.DummyHandler
>
> requestHandler1 = org.apache.ws.axis.security.WSDoAllSender
>
> # These are the handlers for the Listener's request path. Listener's
> request 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.
>
> listenerRequestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> listenerRequestHandler2 =
> org.apache.axis.message.addressing.handler.AddressingHandler
> listenerRequestHandler3 =
> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>
>
> # Define the strategy for executing web service invokes.
> # This impl uses the apache axis thread pool and configures
> # it to the given size.
> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>
> # Define the invoke handler that will execute the web service invokes.
> # This impl simply delegates to the handler specified by the "invoker"
> param.
> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>
> # 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.
>
> ServerINHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
> ServerINHandler1Param1 = action:Encrypt
> ServerINHandler1Param2 = decryptionPropFile:crypto.properties
> ServerINHandler1Param3 =
> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>
> #Configure handlers for the OUT path of the server side sender.
> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllSender
> ListenerOUTHandler1Param1 = action:Encrypt
> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
> ListenerOUTHandler1Param4 =
> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
> ListenerOUTHandler1Param5 =
> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Did you set the required parameters correctly for the WSDoAllSender and
WSDoAllReceiver.
I did not correct them in my mail, and just swapped the names
- Jaliya
----- Original Message -----
From: "Benjamin Schmeling" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Sent: Tuesday, May 30, 2006 2:05 PM
Subject: Re: WSS4J+ Sandesha1.0
Hi,
thanks for your help, but for now with your property file and the
WSDoAllSender in the request and response path there is no message from
the SandeshaClientService visible in the TCPMonitor but the following error:
30 Mai 2006 19:41:20,770 ERROR - WSDoAllSender: No action defined
> Hi,
>
> Please see my comments below.
>
> Thanks,
> - Jaliya
> ----- Original Message ----- From: "Benjamin Schmeling"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Cc: <sa...@ws.apache.org>
> Sent: Tuesday, May 30, 2006 4:30 AM
> Subject: Re: WSS4J+ Sandesha1.0
>
>
> Hi,
>
> I did this like you said, the result is that the target Web Service
> throws a fault:" Did not understand "MustUnderstand" header(s)"
>
> This happens because the message contains some headers with MustUnderstand
> =true but there is no handler to interpret the MustUnderstand Header.
>
> I do not understand why I should put "WSDoAllSender in the server side
> sender's OUT path ".
>
> Sandesha and WSS4J provide two QoSs and they don't have any dependency
> between them. So if we need both reliable messaging and security we need
> to configure both in the correct order.
>
> Say you need only the security, then what will be your configuration. We
> need WSDoAllReceiver in the Web Services request path and the
> WSDoAllSender in the Service's response path.
>
> In Sandesha we cannot use the normal response path of axis because
> according to the RM specification request and response should be in two
> sequences. So we use a separate sender for sending in both client side and
> server side.
>
> Now when we combine both Sandesha and WSS4J we need to arrange the
> handlers as I have explained earlier.
>
>
> The problem at the moment is that the target
> service does not understand the security headers because there is no
> security handler defined for it but only a RMServerRequestHandler. This
> Handler should get affected from the changes in the sandesha.properties
> ? And it should decrypt my message?
>
> RMServerRequestHandler will not perform any security related processing.
> So you need to configure WSDoAllReciver before this handler to do the
> decryption.
>
> But if so would it not decline the
> StartSequence message that is without a Security header (like it was the
> case when I defined it directly as a request handler)?
>
> As long as the RM headers are not encrypted Sandesha handlers should work.
> The must understand fault is generated from axis because of the reason I
> have mentioned above.
>
> I attached my
> servers sandesha.properties file.
>
> Oops, seems like you have changed the sender and receiver, check the
> attached file.
> In addition to the above you need to configure WSDoAllReciver in the
> server-config.wsdd before the addressing and RM handlers in the request
> path. (this was correctly done in your previous mail)
>
>
> Thanks,
>
> Benjamin
>
>
>> 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"
>> <Be...@gmx.de>
>> To: "Jaliya Ekanayake" <ja...@apache.org>
>> Cc: <sa...@ws.apache.org>
>> 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/Cx62
FJS
>>
>> 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"
>>> <Be...@gmx.de>
>>> To: <sa...@ws.apache.org>
>>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
> --------------------------------------------------------------------------------
>
>
>
>> # This is the port in which client side listener listens.
>> CLIENT_LISTENER_PORT = 9090
>>
>> # This is the SimpleAxisServerImpl running port. Only for testing
>> purposes.
>> SIMPLE_AXIS_SERVER_PORT = 8080
>>
>> # Any number of handlers can be included as shown below for the response
>> path of the Sender.
>>
>> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>> responseHandler1 =
>> org.apache.axis.message.addressing.handler.AddressingHandler
>> responseHandler2 =
>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>
>>
>> # If there are additional handlers that needs to be included in the
>> Senders request path
>> # then use the following configuration.
>> # requestHandler1 = package.name.DummyHandler
>>
>> #requestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>
>> # These are the handlers for the Listener's request path. Listener's
>> request 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.
>>
>>
>> listenerRequestHandler1 =
>> org.apache.axis.message.addressing.handler.AddressingHandler
>> listenerRequestHandler2 =
>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>> #listenerRequestHandler3 = org.apache.ws.axis.security.WSDoAllReceiver
>>
>> # Define the strategy for executing web service invokes.
>> # This impl uses the apache axis thread pool and configures
>> # it to the given size.
>> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>>
>> # Define the invoke handler that will execute the web service invokes.
>> # This impl simply delegates to the handler specified by the "invoker"
>> param.
>> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>>
>> # 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.
>>
>> #ServerINHandler1 = org.apache.ws.axis.security.WSDoAllSender
>> #ServerINHandler1Param1 = action:Encrypt
>> #ServerINHandler1Param2 = decryptionPropFile:crypto.properties
>> #ServerINHandler1Param3 =
>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>
>> #Configure handlers for the OUT path of the server side sender.
>> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>> ListenerOUTHandler1Param1 = action:Encrypt
>> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
>> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
>> ListenerOUTHandler1Param4 =
>> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
>> ListenerOUTHandler1Param5 =
>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Did you set the required parameters correctly for the WSDoAllSender and
WSDoAllReceiver.
I did not correct them in my mail, and just swapped the names
- Jaliya
----- Original Message -----
From: "Benjamin Schmeling" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Sent: Tuesday, May 30, 2006 2:05 PM
Subject: Re: WSS4J+ Sandesha1.0
Hi,
thanks for your help, but for now with your property file and the
WSDoAllSender in the request and response path there is no message from
the SandeshaClientService visible in the TCPMonitor but the following error:
30 Mai 2006 19:41:20,770 ERROR - WSDoAllSender: No action defined
> Hi,
>
> Please see my comments below.
>
> Thanks,
> - Jaliya
> ----- Original Message ----- From: "Benjamin Schmeling"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Cc: <sa...@ws.apache.org>
> Sent: Tuesday, May 30, 2006 4:30 AM
> Subject: Re: WSS4J+ Sandesha1.0
>
>
> Hi,
>
> I did this like you said, the result is that the target Web Service
> throws a fault:" Did not understand "MustUnderstand" header(s)"
>
> This happens because the message contains some headers with MustUnderstand
> =true but there is no handler to interpret the MustUnderstand Header.
>
> I do not understand why I should put "WSDoAllSender in the server side
> sender's OUT path ".
>
> Sandesha and WSS4J provide two QoSs and they don't have any dependency
> between them. So if we need both reliable messaging and security we need
> to configure both in the correct order.
>
> Say you need only the security, then what will be your configuration. We
> need WSDoAllReceiver in the Web Services request path and the
> WSDoAllSender in the Service's response path.
>
> In Sandesha we cannot use the normal response path of axis because
> according to the RM specification request and response should be in two
> sequences. So we use a separate sender for sending in both client side and
> server side.
>
> Now when we combine both Sandesha and WSS4J we need to arrange the
> handlers as I have explained earlier.
>
>
> The problem at the moment is that the target
> service does not understand the security headers because there is no
> security handler defined for it but only a RMServerRequestHandler. This
> Handler should get affected from the changes in the sandesha.properties
> ? And it should decrypt my message?
>
> RMServerRequestHandler will not perform any security related processing.
> So you need to configure WSDoAllReciver before this handler to do the
> decryption.
>
> But if so would it not decline the
> StartSequence message that is without a Security header (like it was the
> case when I defined it directly as a request handler)?
>
> As long as the RM headers are not encrypted Sandesha handlers should work.
> The must understand fault is generated from axis because of the reason I
> have mentioned above.
>
> I attached my
> servers sandesha.properties file.
>
> Oops, seems like you have changed the sender and receiver, check the
> attached file.
> In addition to the above you need to configure WSDoAllReciver in the
> server-config.wsdd before the addressing and RM handlers in the request
> path. (this was correctly done in your previous mail)
>
>
> Thanks,
>
> Benjamin
>
>
>> 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"
>> <Be...@gmx.de>
>> To: "Jaliya Ekanayake" <ja...@apache.org>
>> Cc: <sa...@ws.apache.org>
>> 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/Cx62
FJS
>>
>> 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"
>>> <Be...@gmx.de>
>>> To: <sa...@ws.apache.org>
>>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
> --------------------------------------------------------------------------------
>
>
>
>> # This is the port in which client side listener listens.
>> CLIENT_LISTENER_PORT = 9090
>>
>> # This is the SimpleAxisServerImpl running port. Only for testing
>> purposes.
>> SIMPLE_AXIS_SERVER_PORT = 8080
>>
>> # Any number of handlers can be included as shown below for the response
>> path of the Sender.
>>
>> #responseHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>> responseHandler1 =
>> org.apache.axis.message.addressing.handler.AddressingHandler
>> responseHandler2 =
>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>>
>>
>> # If there are additional handlers that needs to be included in the
>> Senders request path
>> # then use the following configuration.
>> # requestHandler1 = package.name.DummyHandler
>>
>> #requestHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>>
>> # These are the handlers for the Listener's request path. Listener's
>> request 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.
>>
>>
>> listenerRequestHandler1 =
>> org.apache.axis.message.addressing.handler.AddressingHandler
>> listenerRequestHandler2 =
>> org.apache.sandesha.ws.rm.handlers.RMServerRequestHandler
>> #listenerRequestHandler3 = org.apache.ws.axis.security.WSDoAllReceiver
>>
>> # Define the strategy for executing web service invokes.
>> # This impl uses the apache axis thread pool and configures
>> # it to the given size.
>> invokeStrategy=org.apache.sandesha.server.ThreadPoolInvokeStrategy:threadPoolSize=10
>>
>> # Define the invoke handler that will execute the web service invokes.
>> # This impl simply delegates to the handler specified by the "invoker"
>> param.
>> invokeHandler=org.apache.sandesha.server.DelegateInvokeHandler:invoker=org.apache.axis.providers.java.RPCProvider
>>
>> # 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.
>>
>> #ServerINHandler1 = org.apache.ws.axis.security.WSDoAllSender
>> #ServerINHandler1Param1 = action:Encrypt
>> #ServerINHandler1Param2 = decryptionPropFile:crypto.properties
>> #ServerINHandler1Param3 =
>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>
>> #Configure handlers for the OUT path of the server side sender.
>> ListenerOUTHandler1 = org.apache.ws.axis.security.WSDoAllReceiver
>> ListenerOUTHandler1Param1 = action:Encrypt
>> ListenerOUTHandler1Param2 = encryptionPropFile:crypto.properties
>> ListenerOUTHandler1Param3 = encryptionKeyIdentifier:X509KeyIdentifier
>> ListenerOUTHandler1Param4 =
>> encryptionUser:16c73ab6-b892-458f-abf5-2f875f74882e
>> ListenerOUTHandler1Param5 =
>> passwordCallbackClass:de.tud.ao4bpel.services.security.wss4jhandler.WSS4JPasswordCallbackHandler
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi,
I did this like you said, the result is that the target Web Service
throws a fault:" Did not understand "MustUnderstand" header(s)"
I do not understand why I should put "WSDoAllSender in the server side
sender's OUT path ". The problem at the moment is that the target
service does not understand the security headers because there is no
security handler defined for it but only a RMServerRequestHandler. This
Handler should get affected from the changes in the sandesha.properties
? And it should decrypt my message? But if so would it not decline the
StartSequence message that is without a Security header (like it was the
case when I defined it directly as a request handler)? I attached my
servers sandesha.properties file.
Thanks,
Benjamin
> 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"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Cc: <sa...@ws.apache.org>
> 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"
>> <Be...@gmx.de>
>> To: <sa...@ws.apache.org>
>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
Re: WSS4J+ Sandesha1.0
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi,
I did this like you said, the result is that the target Web Service
throws a fault:" Did not understand "MustUnderstand" header(s)"
I do not understand why I should put "WSDoAllSender in the server side
sender's OUT path ". The problem at the moment is that the target
service does not understand the security headers because there is no
security handler defined for it but only a RMServerRequestHandler. This
Handler should get affected from the changes in the sandesha.properties
? And it should decrypt my message? But if so would it not decline the
StartSequence message that is without a Security header (like it was the
case when I defined it directly as a request handler)? I attached my
servers sandesha.properties file.
Thanks,
Benjamin
> 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"
> <Be...@gmx.de>
> To: "Jaliya Ekanayake" <ja...@apache.org>
> Cc: <sa...@ws.apache.org>
> 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"
>> <Be...@gmx.de>
>> To: <sa...@ws.apache.org>
>> 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: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Cc: <sa...@ws.apache.org>
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"
> <Be...@gmx.de>
> To: <sa...@ws.apache.org>
> 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: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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" <Be...@gmx.de>
To: "Jaliya Ekanayake" <ja...@apache.org>
Cc: <sa...@ws.apache.org>
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"
> <Be...@gmx.de>
> To: <sa...@ws.apache.org>
> 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: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Benjamin Schmeling <Be...@gmx.de>.
> 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/Cx62FJSciVZzIpAddP+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"
> <Be...@gmx.de>
> To: <sa...@ws.apache.org>
> 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: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Benjamin Schmeling <Be...@gmx.de>.
> 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/Cx62FJSciVZzIpAddP+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"
> <Be...@gmx.de>
> To: <sa...@ws.apache.org>
> 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: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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. 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.
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" <Be...@gmx.de>
To: <sa...@ws.apache.org>
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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSS4J+ Sandesha1.0
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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. 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.
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" <Be...@gmx.de>
To: <sa...@ws.apache.org>
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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org