You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Jamie Lyon <jl...@it-innovation.soton.ac.uk> on 2007/07/31 11:41:41 UTC
[Rampart/C] Generating incorrect digests?
Hi,
I'm trying to get a client signing messages to work with a server using
Axis1/WSS4J.
I've successfully got Rampart/C set up, and have the client signing
messages, however the digests are failing to verify for all items apart
from the Body.
It might also be of interest that even with just <sp:Body/> in the
SignedParts, the timestamp is still signed, so I can't test to see if
the message is accepted when only the Body is signed (is there a way to
turn this off?). There is also the message "No Signed parts specified.
Using the body." when only the body is specified.
An error that might be significant is: "OXS ERROR [x509.c:385 in
openssl_x509_get_subject_key_identifier] oxs defualt error , The
extenension index of NID_subject_key_identifier is not valid" (spelling
mistakes in original error message).
I've included the policy.xml and axis2.xml files, as well as the .cpp
file I'm using, and the debug.log (axis2/c log) and tcplog.log (tcpmon's
log).
Finally, here is debug output from tomcat (there will be more
verification failed for URI if I tell rampart/c to sign more elements):
2007-07-31 10:30:42,989 WARN
[org.apache.xml.security.signature.Reference]
(http-8080-Processor25:?:?) Verification failed for URI
"#SigID-b547854a-3f48-1dc1"
org.apache.ws.security.WSSecurityException: The signature verification
failed
at
org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(S
ignatureProcessor.java:327)
at
org.apache.ws.security.processor.SignatureProcessor.handleToken(Signatur
eProcessor.java:79)
Thanks,
Jamie
Re: [Rampart/C] Generating incorrect digests?
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
You are welcome. :)
The reason might be having two prefixes pointing to the same namespace
in the Timestamp. Which I consider legal. So the digest calculation
based on C14N might differ in two implementations. Anyways thank you
too, for pointing this out.
Cheers,
Kaushalye
Jamie Lyon wrote:
> This works perfectly, thanks very much!
>
> Cheers,
> Jamie
>
>
>> -----Original Message-----
>> From: Kaushalye Kapuruge [mailto:kaushalye@wso2.com]
>> Sent: 01 August 2007 06:30
>> To: Apache AXIS C Developers List
>> Subject: Re: [Rampart/C] Generating incorrect digests?
>>
>> Hi Jamie,
>> It appears to me that the tcp log and the server log don't tally.
>> The tcp-log shows attribute in Timestamp as u:Id whilst the server-log
>> shows wsu:Id.
>> May be the server expects attribute to be with wsu: prefix.
>> Could you please try this...
>> 1. Open RAMPART/src/util/rampart_signature.c
>> 2. Change line(273) to
>> oxs_axiom_add_attribute(env, node_to_sign, RAMPART_WSU,
>> RAMPART_WSU_XMLNS,OXS_ATTR_ID, id);
>> See that I've changed prefix, from "u:" to "wsu:"
>> Let me know if this works with Axis1. If not we might have to dig
>> further into the problem :).
>> Cheers,
>> Kaushalye
>>
>> Jamie Lyon wrote:
>>
>>> Replies inline:
>>>
>>>
>>>
>>>>> I've successfully got Rampart/C set up, and have the client
>>>>>
> signing
>
>>>>> messages, however the digests are failing to verify for all items
>>>>> apart from the Body.
>>>>>
>>>>>
>>>>>
>>>> You mean the digest of the body is verified but not for other
>>>>
> parts?
>
>>> It appears to be that way, yes. At least, the Axis1/Java isn't
>>>
> throwing
>
>>> any verification failed errors for the Body.
>>>
>>>
>>>
>>>>> It might also be of interest that even with just <sp:Body/> in the
>>>>> SignedParts, the timestamp is still signed, so I can't test to see
>>>>>
>>>>>
>>> if
>>>
>>>
>>>>> the message is accepted when only the Body is signed (is there a
>>>>>
> way
>
>>>>> to turn this off?). There is also the message "No Signed parts
>>>>> specified. Using the body." when only the body is specified.
>>>>>
>>>>>
>>>>>
>>>> The behavior is, if a Timestamp is present Rampart/C signs it as
>>>>
> per
>
>>> the
>>>
>>>
>>>> WS-Security Policy Specification(Section 7.2).
>>>> So if signing is enabled, and there is a Timestamp, Rampart/C signs
>>>>
>>>>
>>> it.
>>>
>>> Okay, this is fine, I would want to sign it eventually anyway, I was
>>> just curious as to whether there was a way to disable it for testing
>>> purposes.
>>>
>>>
>>>
>>>>> An error that might be significant is: "OXS ERROR [x509.c:385 in
>>>>> openssl_x509_get_subject_key_identifier] oxs defualt error , The
>>>>> extenension index of NID_subject_key_identifier is not valid"
>>>>> (spelling mistakes in original error message).
>>>>>
>>>>>
>>>>>
>>>> Did you get this error in the client side? (Since you are using
>>>> Rampart/C client against WSS4J )
>>>>
>>>>
>>> Yes, that's from the client with Axis2/C|Rampart/C, it can be seen
>>>
> in
>
>>> the debug.log I included with the last message, just above the first
>>> c14n debug output, but it's also printed to the screen when running.
>>>
>>>
>>>
>>>> The reference belongs to the Timestamp element, in which the digest
>>>> verification fails. But the problem is how the Body signature was
>>>> verified? (please confirm this).
>>>> Have you tried to use Rampart/C for the verification of a message
>>>>
>>>>
>>> signed
>>>
>>>
>>>> by WSS4J?
>>>> BTW, Rampart/C interop with Rampart/Java, which uses WSS4J. :)
>>>>
>>>>
>>> I've attached the Axis logs for messages with and without a
>>>
> timestamp.
>
>>> It appears to me as though the one without the timestamp is being
>>> verified correctly, although it then of course returns to me a
>>> 'timestamp missing' error.
>>>
>>> Could the problem be that the c14n transforms are not working
>>>
> correctly?
>
>>> I'm currently trying to get axis/java to output the xml that it is
>>> producing a digest on, to make sure that they match.
>>>
>>> Thanks,
>>> Jamie
>>>
>>>
>>>
> ------------------------------------------------------------------------
>
>>>
> ---------------------------------------------------------------------
>
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>> --
>> http://kaushalye.blogspot.com/
>> http://wso2.org/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
--
http://kaushalye.blogspot.com/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: [Rampart/C] Generating incorrect digests?
Posted by Jamie Lyon <jl...@it-innovation.soton.ac.uk>.
This works perfectly, thanks very much!
Cheers,
Jamie
> -----Original Message-----
> From: Kaushalye Kapuruge [mailto:kaushalye@wso2.com]
> Sent: 01 August 2007 06:30
> To: Apache AXIS C Developers List
> Subject: Re: [Rampart/C] Generating incorrect digests?
>
> Hi Jamie,
> It appears to me that the tcp log and the server log don't tally.
> The tcp-log shows attribute in Timestamp as u:Id whilst the server-log
> shows wsu:Id.
> May be the server expects attribute to be with wsu: prefix.
> Could you please try this...
> 1. Open RAMPART/src/util/rampart_signature.c
> 2. Change line(273) to
> oxs_axiom_add_attribute(env, node_to_sign, RAMPART_WSU,
> RAMPART_WSU_XMLNS,OXS_ATTR_ID, id);
> See that I've changed prefix, from "u:" to "wsu:"
> Let me know if this works with Axis1. If not we might have to dig
> further into the problem :).
> Cheers,
> Kaushalye
>
> Jamie Lyon wrote:
> > Replies inline:
> >
> >
> >>> I've successfully got Rampart/C set up, and have the client
signing
> >>> messages, however the digests are failing to verify for all items
> >>> apart from the Body.
> >>>
> >>>
> >> You mean the digest of the body is verified but not for other
parts?
> >>
> >
> > It appears to be that way, yes. At least, the Axis1/Java isn't
throwing
> > any verification failed errors for the Body.
> >
> >
> >>> It might also be of interest that even with just <sp:Body/> in the
> >>> SignedParts, the timestamp is still signed, so I can't test to see
> >>>
> > if
> >
> >>> the message is accepted when only the Body is signed (is there a
way
> >>> to turn this off?). There is also the message "No Signed parts
> >>> specified. Using the body." when only the body is specified.
> >>>
> >>>
> >> The behavior is, if a Timestamp is present Rampart/C signs it as
per
> >>
> > the
> >
> >> WS-Security Policy Specification(Section 7.2).
> >> So if signing is enabled, and there is a Timestamp, Rampart/C signs
> >>
> > it.
> >
> > Okay, this is fine, I would want to sign it eventually anyway, I was
> > just curious as to whether there was a way to disable it for testing
> > purposes.
> >
> >
> >>> An error that might be significant is: "OXS ERROR [x509.c:385 in
> >>> openssl_x509_get_subject_key_identifier] oxs defualt error , The
> >>> extenension index of NID_subject_key_identifier is not valid"
> >>> (spelling mistakes in original error message).
> >>>
> >>>
> >> Did you get this error in the client side? (Since you are using
> >> Rampart/C client against WSS4J )
> >>
> >
> > Yes, that's from the client with Axis2/C|Rampart/C, it can be seen
in
> > the debug.log I included with the last message, just above the first
> > c14n debug output, but it's also printed to the screen when running.
> >
> >
> >> The reference belongs to the Timestamp element, in which the digest
> >> verification fails. But the problem is how the Body signature was
> >> verified? (please confirm this).
> >> Have you tried to use Rampart/C for the verification of a message
> >>
> > signed
> >
> >> by WSS4J?
> >> BTW, Rampart/C interop with Rampart/Java, which uses WSS4J. :)
> >>
> >
> > I've attached the Axis logs for messages with and without a
timestamp.
> > It appears to me as though the one without the timestamp is being
> > verified correctly, although it then of course returns to me a
> > 'timestamp missing' error.
> >
> > Could the problem be that the c14n transforms are not working
correctly?
> > I'm currently trying to get axis/java to output the xml that it is
> > producing a digest on, to make sure that they match.
> >
> > Thanks,
> > Jamie
> >
> >
------------------------------------------------------------------------
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> --
> http://kaushalye.blogspot.com/
> http://wso2.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: [Rampart/C] Generating incorrect digests?
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Hi Jamie,
It appears to me that the tcp log and the server log don't tally.
The tcp-log shows attribute in Timestamp as u:Id whilst the server-log
shows wsu:Id.
May be the server expects attribute to be with wsu: prefix.
Could you please try this...
1. Open RAMPART/src/util/rampart_signature.c
2. Change line(273) to
oxs_axiom_add_attribute(env, node_to_sign, RAMPART_WSU,
RAMPART_WSU_XMLNS,OXS_ATTR_ID, id);
See that I've changed prefix, from "u:" to "wsu:"
Let me know if this works with Axis1. If not we might have to dig
further into the problem :).
Cheers,
Kaushalye
Jamie Lyon wrote:
> Replies inline:
>
>
>>> I've successfully got Rampart/C set up, and have the client signing
>>> messages, however the digests are failing to verify for all items
>>> apart from the Body.
>>>
>>>
>> You mean the digest of the body is verified but not for other parts?
>>
>
> It appears to be that way, yes. At least, the Axis1/Java isn't throwing
> any verification failed errors for the Body.
>
>
>>> It might also be of interest that even with just <sp:Body/> in the
>>> SignedParts, the timestamp is still signed, so I can't test to see
>>>
> if
>
>>> the message is accepted when only the Body is signed (is there a way
>>> to turn this off?). There is also the message "No Signed parts
>>> specified. Using the body." when only the body is specified.
>>>
>>>
>> The behavior is, if a Timestamp is present Rampart/C signs it as per
>>
> the
>
>> WS-Security Policy Specification(Section 7.2).
>> So if signing is enabled, and there is a Timestamp, Rampart/C signs
>>
> it.
>
> Okay, this is fine, I would want to sign it eventually anyway, I was
> just curious as to whether there was a way to disable it for testing
> purposes.
>
>
>>> An error that might be significant is: "OXS ERROR [x509.c:385 in
>>> openssl_x509_get_subject_key_identifier] oxs defualt error , The
>>> extenension index of NID_subject_key_identifier is not valid"
>>> (spelling mistakes in original error message).
>>>
>>>
>> Did you get this error in the client side? (Since you are using
>> Rampart/C client against WSS4J )
>>
>
> Yes, that's from the client with Axis2/C|Rampart/C, it can be seen in
> the debug.log I included with the last message, just above the first
> c14n debug output, but it's also printed to the screen when running.
>
>
>> The reference belongs to the Timestamp element, in which the digest
>> verification fails. But the problem is how the Body signature was
>> verified? (please confirm this).
>> Have you tried to use Rampart/C for the verification of a message
>>
> signed
>
>> by WSS4J?
>> BTW, Rampart/C interop with Rampart/Java, which uses WSS4J. :)
>>
>
> I've attached the Axis logs for messages with and without a timestamp.
> It appears to me as though the one without the timestamp is being
> verified correctly, although it then of course returns to me a
> 'timestamp missing' error.
>
> Could the problem be that the c14n transforms are not working correctly?
> I'm currently trying to get axis/java to output the xml that it is
> producing a digest on, to make sure that they match.
>
> Thanks,
> Jamie
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
--
http://kaushalye.blogspot.com/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: [Rampart/C] Generating incorrect digests?
Posted by Jamie Lyon <jl...@it-innovation.soton.ac.uk>.
Replies inline:
> > I've successfully got Rampart/C set up, and have the client signing
> > messages, however the digests are failing to verify for all items
> > apart from the Body.
> >
> You mean the digest of the body is verified but not for other parts?
It appears to be that way, yes. At least, the Axis1/Java isn't throwing
any verification failed errors for the Body.
> > It might also be of interest that even with just <sp:Body/> in the
> > SignedParts, the timestamp is still signed, so I can't test to see
if
> > the message is accepted when only the Body is signed (is there a way
> > to turn this off?). There is also the message "No Signed parts
> > specified. Using the body." when only the body is specified.
> >
> The behavior is, if a Timestamp is present Rampart/C signs it as per
the
> WS-Security Policy Specification(Section 7.2).
> So if signing is enabled, and there is a Timestamp, Rampart/C signs
it.
Okay, this is fine, I would want to sign it eventually anyway, I was
just curious as to whether there was a way to disable it for testing
purposes.
> > An error that might be significant is: "OXS ERROR [x509.c:385 in
> > openssl_x509_get_subject_key_identifier] oxs defualt error , The
> > extenension index of NID_subject_key_identifier is not valid"
> > (spelling mistakes in original error message).
> >
> Did you get this error in the client side? (Since you are using
> Rampart/C client against WSS4J )
Yes, that's from the client with Axis2/C|Rampart/C, it can be seen in
the debug.log I included with the last message, just above the first
c14n debug output, but it's also printed to the screen when running.
> The reference belongs to the Timestamp element, in which the digest
> verification fails. But the problem is how the Body signature was
> verified? (please confirm this).
> Have you tried to use Rampart/C for the verification of a message
signed
> by WSS4J?
> BTW, Rampart/C interop with Rampart/Java, which uses WSS4J. :)
I've attached the Axis logs for messages with and without a timestamp.
It appears to me as though the one without the timestamp is being
verified correctly, although it then of course returns to me a
'timestamp missing' error.
Could the problem be that the c14n transforms are not working correctly?
I'm currently trying to get axis/java to output the xml that it is
producing a digest on, to make sure that they match.
Thanks,
Jamie
Re: [Rampart/C] Generating incorrect digests?
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Hi,
See my comments in-line...
Cheers,
Kaushalye
Jamie Lyon wrote:
>
> Hi,
>
> I’m trying to get a client signing messages to work with a server
> using Axis1/WSS4J.
>
> I’ve successfully got Rampart/C set up, and have the client signing
> messages, however the digests are failing to verify for all items
> apart from the Body.
>
You mean the digest of the body is verified but not for other parts?
>
> It might also be of interest that even with just <sp:Body/> in the
> SignedParts, the timestamp is still signed, so I can’t test to see if
> the message is accepted when only the Body is signed (is there a way
> to turn this off?). There is also the message “No Signed parts
> specified. Using the body.” when only the body is specified.
>
The behavior is, if a Timestamp is present Rampart/C signs it as per the
WS-Security Policy Specification(Section 7.2).
So if signing is enabled, and there is a Timestamp, Rampart/C signs it.
>
> An error that might be significant is: “OXS ERROR [x509.c:385 in
> openssl_x509_get_subject_key_identifier] oxs defualt error , The
> extenension index of NID_subject_key_identifier is not valid”
> (spelling mistakes in original error message).
>
Did you get this error in the client side? (Since you are using
Rampart/C client against WSS4J )
>
> I’ve included the policy.xml and axis2.xml files, as well as the .cpp
> file I’m using, and the debug.log (axis2/c log) and tcplog.log
> (tcpmon’s log).
>
> Finally, here is debug output from tomcat (there will be more
> verification failed for URI if I tell rampart/c to sign more elements):
>
> 2007-07-31 10:30:42,989 WARN
> [org.apache.xml.security.signature.Reference]
> (http-8080-Processor25:?:?) Verification failed for URI
> "#SigID-b547854a-3f48-1dc1"
>
> org.apache.ws.security.WSSecurityException: The signature verification
> failed
>
> at
> org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:327)
>
> at
> org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:79)
>
The reference belongs to the Timestamp element, in which the digest
verification fails. But the problem is how the Body signature was
verified? (please confirm this).
Have you tried to use Rampart/C for the verification of a message signed
by WSS4J?
BTW, Rampart/C interop with Rampart/Java, which uses WSS4J. :)
>
> Thanks,
>
> Jamie
>
> ------------------------------------------------------------------------
>
> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
> <wsp:ExactlyOne>
> <wsp:All>
> <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
> <wsp:Policy>
> <sp:WssX509V3Token10/>
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:InitiatorToken>
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
> <wsp:Policy>
> <sp:WssX509V3Token10/>
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic256Rsa15/>
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Strict/>
> </wsp:Policy>
> </sp:Layout>
> <sp:IncludeTimestamp/>
> <!--sp:EncryptSignature/-->
> <!--sp:EncryptBeforeSigning/-->
> </wsp:Policy>
> </sp:AsymmetricBinding>
> <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:MustSupportRefKeyIdentifier/>
> <sp:MustSupportRefEmbeddedToken/>
> <sp:MustSupportRefIssuerSerial/>
> </wsp:Policy>
> </sp:Wss10>
> <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <sp:Body/>
> <!--sp:Header Namespace="http://www.w3.org/2005/08/addressing"/-->
> </sp:SignedParts>
> <rampc:RampartConfig xmlns:rampc="http://ws.apache.org/rampart/c/policy">
> <rampc:ReceiverCertificate>/home/jl/cacert.pem</rampc:ReceiverCertificate>
> <rampc:Certificate>/home/jl/mycert.pem</rampc:Certificate>
> <rampc:PrivateKey>/home/jl/mykey.pem</rampc:PrivateKey>
> </rampc:RampartConfig>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> ------------------------------------------------------------------------
>
> <axisconfig name="Axis2/C">
> <!-- ================================================= -->
> <!-- Parameters -->
> <!-- ================================================= -->
> <!-- Uncomment following to enable MTOM support -->
> <!--parameter name="enableMTOM" locked="false">true</parameter-->
> <parameter name="enableREST" locked="false">true</parameter>
>
> <!-- Uncomment following to persist op_ctx, useful with RM -->
> <!--parameter name="persistOperationContext" locked="false">true</parameter-->
>
> <!--if you want to extract the service archive file and work with that please uncomment this-->
> <!--else , it wont extract archive file or does not take into consideration if someone drop-->
> <!--exploded directory into /service directory-->
> <!--<parameter name="extractServiceArchive" locked="false">true</parameter>-->
>
>
> <!-- ================================================= -->
> <!-- Message Receivers -->
> <!-- ================================================= -->
> <!-- This is the Deafult Message Receiver for the Request Response style Operations -->
> <!--messageReceiver mep="INOUT" class="axis2_receivers"/-->
>
> <!-- ================================================= -->
> <!-- Transport Ins -->
> <!-- ================================================= -->
> <transportReceiver name="http" class="axis2_http_receiver">
> <parameter name="port" locked="false">6060</parameter>
> </transportReceiver>
>
> <!-- ================================================= -->
> <!-- Transport Outs -->
> <!-- ================================================= -->
>
> <transportSender name="http" class="axis2_http_sender">
> <parameter name="PROTOCOL" locked="false">HTTP/1.1</parameter>
> <!--parameter name="Transfer-Encoding">chunked</parameter-->
> <!--parameter name="PROXY" proxy_host="127.0.0.1" proxy_port="8080" locked="true"/-->
> </transportSender>
> <!-- Uncomment this one with the appropriate papameters to enable the XMPP transport Sender-->
> <!--transportSender name="xmpp" class="axis2_xmpp_sender">
> <parameter name="PROTOCOL" locked="false">XMPP</parameter>
> </transportSender-->
> <!-- Uncomment this one with the appropriate papameters to enable the TCP transport Sender-->
> <!--transportSender name="tcp" class="axis2_tcp_sender">
> <parameter name="PROTOCOL" locked="false">TCP</parameter>
> </transportSender-->
>
> <!--
> <transportSender name="https" class="axis2_http_sender">
> <parameter name="PROTOCOL" locked="false">HTTP/1.1</parameter>
> </transportSender>
> <parameter name="SERVER_CERT">/path/to/ca/certificate</parameter>
> <parameter name="KEY_FILE">/path/to/client/certificate/chain/file</parameter>
> <parameter name="SSL_PASSPHRASE">passphrase</parameter>
> -->
>
>
> <!-- ================================================= -->
> <!-- Global Modules -->
> <!-- ================================================= -->
> <!-- Comment this to disable Addressing -->
> <module ref="addressing"/>
> <module ref="rampart"/>
>
>
> <!--Configuring module , providing paramters for modules whether they refer or not-->
> <!--<moduleConfig name="addressing">-->
> <!--<parameter name="addressingPara" locked="false">N/A</parameter>-->
> <!--</moduleConfig>-->
>
> <!-- ================================================= -->
> <!-- Phases -->
> <!-- ================================================= -->
> <phaseOrder type="inflow">
> <!-- System pre defined phases -->
> <phase name="Transport"/>
> <phase name="PreDispatch"/>
> <phase name="Dispatch"/>
> <phase name="PostDispatch"/>
> <!-- End system pre defined phases -->
> <!-- After PostDispatch phase, module or service author can add any phase as required -->
> <!-- User defined phases could be added here -->
> <!--phase name="userphase1"/-->
> <!--phase name="RMPhase"/-->
> <!--phase name="SavanPhase"/-->
> </phaseOrder>
> <phaseOrder type="outflow">
> <!-- User defined phases could be added here -->
> <!--phase name="RMPhase"/-->
> <!--phase name="SavanPhase"/-->
> <!--phase name="userphase1"/-->
> <!--system predefined phase-->
> <phase name="MessageOut"/>
> </phaseOrder>
> <phaseOrder type="INfaultflow">
> <!-- User defined phases could be added here -->
> <!--phase name="userphase1"/-->
> <!--phase name="RMPhase"/-->
> <!--phase name="SavanPhase"/-->
> </phaseOrder>
> <phaseOrder type="Outfaultflow">
> <!-- User defined phases could be added here -->
> <!--phase name="RMPhase"/-->
> <!--phase name="SavanPhase"/-->
> <!--phase name="userphase1"/-->
> <phase name="MessageOut"/>
> </phaseOrder>
> </axisconfig>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
--
http://kaushalye.blogspot.com/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org