Re: CXF logging
I got log4j working with the info here: http://www.techper.net/2008/01/30/configuring-cxf-logging-to-go-through-log4j/ I wasn't sure how to setup the META-INF for my war file. I eventually figured out that you need to include a folder called /META-INF/cxf/ with a text file called org.apache.cxf.Logger file in my war file under .../src/java folder. All you need to do then is put name of the class CXF provides that text file. So in org.apache.cxf.Logger file you put the text string "org.apache.cxf.Logger" with out the quotes. Then its just configuring log4j as usual. John-M Baker <[EMAIL PROTECTED]> 03/06/2008 08:49 AM Please respond to cxf-user@incubator.apache.org To cc Subject CXF logging Hi, What's the best way to turn on debug logging? I'd like to see what XML is being sent from the client and I'm sure that'll be in the debug (well, I hope it is!). I tried a simple log4j.xml file but that iddn't seem to work. Thanks, John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: Deploy my service implementation separately from my security configuration?
Dan, I really appreciate the way you try to answer everyone's questions on this list! I can see from the logs that the message coming back from the real/internal service are identical between JBoss and Websphere. The response is getting back to the generic security service in the same way (as far as I can tell). I am still sorting out what each interceptor is for, etc. Update: On the shared library in Websphere (version is 6.1.0.11) we had an older wsdl4j-1.5.2.jar so I had it replaced with the correct 1.6.1 version and retested. Now I am getting a different error in the same SoapOutInterceptor on the generic security service (actually my version of it MySoapOutInterceptor). I have all of the required jars in my deployed project, but I'm not sure which ones are being overridden by the Websphere servers classloader. Are there any other jars (besides the wsdl4j-1.6.1.jar) that need to be put on the shared library to correct classloader issues? Here is the latest error that comes up with the 1.6.1 version of wsdl4j jar: Trace: 2008/02/15 10:21:20.634 01 t=AC75E0 c=UNK key=P8 (13007002) ThreadId: 001d FunctionName: doIntercept SourceId: org.apache.cxf.phase.PhaseInterceptorChain Category: INFO ExtendedMessage: Interceptor has thrown exception, unwinding noworg.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was ma de to insert a node where it is not permitted. at org.apache.xerces.dom.CoreDocumentImpl.insertBefore(Unknown Source) at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source) at com.ibm.ws.webservices.engine.xmlsoap.SOAPPart.appendChild(SOAPPart.java:244) at org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWriter.java:82) at org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStreamWriter.java:99) at org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.writeSoapEnvelopeStart(MySoapOutInterceptor.java:132) at org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.handleMessage(MySoapOutInterceptor.java:108) at org.aurora.saaj_gateway.interceptors.MySoapOutInterceptor.handleMessage(MySoapOutInterceptor.java:47) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77) at org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:264) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170) at org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:989) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:501) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:464) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3276) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:113) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:454) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:383) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:263) at com.ibm.ws390.channel.xmem.XMemConnLink.ready(XMemConnLink.java:788) at com.ibm.ws390.xmem.XMemSRBridgeImpl.httpinvoke(XMemSRBridgeImpl.java:230) at com.ibm.ws390.xmem.XMemSRCppUtilities.httpinvoke(XMemSRCppUtilities.java:74) at com.ibm.ws390.orb.ServerRegionBridge.httpinvoke(Unknown Source) at com.ibm.ws390.orb.ORBEJSBridge.httpinvoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at com.ibm.ws390.orb.parameters.HTTPIn
Re: Deploy my service implementation separately from my security configuration?
Dan,
I actually got your suggestion working under JBoss 4.0.4GA but am having
issues with running under Websphere.
I am using the SAAJ api's to send the request to the real server and then
the generic service takes care of wrapping the security onto the response.
The service interface keeps it really generic by changing the SOAPMessage
to a string/base64 as needed.
This way any service method can be passed without need to change the
generic service.
@WebService(name="SAAJGatewayService",
targetNamespace="http://services.my.namespace";)
public interface SAAJGatewayService {
String sendMessage (
@WebParam(name = "message")
String message);
}
The real service works under Websphere since its not using any of the
security.
The problem I'm having with the generic service seems to have something to
do with the SAAJ api's conflicting with the servers j2ee.jar (SOAPMessage,
SOAPBody, and SOAPPart classes).
I tried having the jars for the SAAJ put on the Websphere server, but now
it looks like I am having problems mixing com.sun with com.ibm xerces
parsers.
Without the saaj api on the server, I actually had the response coming
back to the generic server, but the SoapOutInterceptor is blowing up on:
ExtendedMessage: Interceptor has thrown exception, unwinding
noworg.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to
insert a node where it is not permitted.
.at org.apache.xerces.dom.CoreDocumentImpl.insertBefore(Unknown Source)
.at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
.at com.ibm
.ws.webservices.engine.xmlsoap.SOAPPart.appendChild(SOAPPart.java:244)
.at
org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWriter.java:82)
.at
org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStreamWriter.java:99)
.at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:95)
.at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
.at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
.at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
.at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74)
.at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
.at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77)
.at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
.at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:264)
.at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
.at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
.at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
etc
I am stuck at this point wondering what is happening to the SOAP object
that could be causing this HIERARCHY_REQUEST_ERR.
Daniel Kulp <[EMAIL PROTECTED]>
02/05/2008 02:50 PM
To
cxf-user@incubator.apache.org
cc
[EMAIL PROTECTED]
Subject
Re: Deploy my service implementation separately from my security
configuration?
You MAY be able to do this by writing a completely generic
Provider based service that just forwards onto another
service. The security information would be set on that and the spring
could configure in a URL to the service it then sends the SOAP messages
onto. It would then use the dispatch APIs (or even the straight SAAJ
apis I think would work if you are talking straight HTTP) to forward the
SAAJ message onto the real server, get the SAAJ back, and return it
where the security would do it's thing.
Dan
On Monday 04 February 2008, [EMAIL PROTECTED] wrote:
> Hello,
>
> I am working with CXF 2.0.4 with javaFirst/Spring/CXF Servlet.
> I have the jaxws setup using Timestamp, Signature, and Encypt.
> I have some customized interceptors and a handler.
>
> This is all included in one war file (just like the demos) that I
> deploy to JBoss (and eventually Websphere).
>
> I was wondering if its possible to:
> - separate out my service implementation as one war file and my
> security configuration as another war file
> or
> - have my service endpoint be external from the same JVM that CXF is
> under (the internal endpoint is different from the published external
> endpoint).
>
>
> The goal is to keep the security settings "untouchable" when further
> maintenance/enhancements of the service methods goes forward.
> We don't want to have to worry about the security getting broken once
> we know that its working correctly.
>
> I believe that this is called "hardening" the security.
>
> Any suggestions/readings would really be appreciated.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http:
Deploy my service implementation separately from my security configuration?
Hello, I am working with CXF 2.0.4 with javaFirst/Spring/CXF Servlet. I have the jaxws setup using Timestamp, Signature, and Encypt. I have some customized interceptors and a handler. This is all included in one war file (just like the demos) that I deploy to JBoss (and eventually Websphere). I was wondering if its possible to: - separate out my service implementation as one war file and my security configuration as another war file or - have my service endpoint be external from the same JVM that CXF is under (the internal endpoint is different from the published external endpoint). The goal is to keep the security settings "untouchable" when further maintenance/enhancements of the service methods goes forward. We don't want to have to worry about the security getting broken once we know that its working correctly. I believe that this is called "hardening" the security. Any suggestions/readings would really be appreciated.
Re: item element with xmlns=""
I am having the same issue trying to return a Collection .
I am using apache-cxf-2.0.4-incubator-SNAPSHOT with Aegis bindings.
http://schemas.xmlsoap.org/soap/envelope/";>http://beans.partner.aurora.org";>
Client throws this error:
Caused by: com.ctc.wstx.exc.WstxParsingException: Non-default namespace
can not map to empty URI (as per Namespace 1.0 # 2) in XML 1.0 documents
at [row,col {unknown-source}]: [1,187]
at
com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:605)
at
com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:461)
at
com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3052)
at
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2934)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2846)
at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)
at
org.apache.cxf.staxutils.DepthXMLStreamReader.next(DepthXMLStreamReader.java:215)
at
org.apache.cxf.staxutils.StaxUtils.nextEvent(StaxUtils.java:132)
... 15 more
I am thinking the issues is the fact that the namespace is mssing in
Marco Piraccini <[EMAIL PROTECTED]>
01/24/2008 10:06 AM
Please respond to
cxf-user@incubator.apache.org
To
cxf-user@incubator.apache.org
cc
Subject
Re: item element with xmlns=""
Thank you Dan for your quick answer.
I already tried with CXF-2.0.4 (RC) but the behaviour seems to be the
same as the 2.0.3
version.
Marco.
Quoting Daniel Kulp <[EMAIL PROTECTED]>:
>
> Any chance you could check with the 2.0.4 release candidates available
> at:
> http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/
>
> There were definite issues with Exceptions not working correctly with
> qualified schemas in 2.0.3. They should (hopefully) be fixed there.
>
> Dan
>
>
> On Thursday 24 January 2008, Marco Piraccini wrote:
>> I need to expose a service (java-first) with CXF with an exception
>> (EchoComplexException
>> ) that includes an array of object (of class EchoStruct).
>> The service is setted with: anonymousWrapperType, qualifyWrapperSchema
>> ad wrapped to true.
>>
>> The wsdl generated seems to be correct, with a wrapper
>> EchoComplexException of the type:
>>
>>
>>
>> > nillable="true" type="tns:echoStruct"/>
>>
>>
>>
>> The problem is that, on object deserialization, the
>> EchoComplexException is serialized in:
>>
>>
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>>
>> true
>>
>>
>>
>>
>> ...that's correct, except for the xmlns="" item namespace. Of course
>> the schema validation fails.
>>
>> Anyone meet the same problem?
>>
>> Marco.
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
Is it possible to pass the security principle from the client request to the response?
Hello, Has anyone used interceptors or handlers to set information in the request so that it comes back in the response? If that is not possible, is there a way to tell CXF to persist attributes in memory so that you can keep track of information that was available in the request for when you intercept the response? What I am trying to do is figure out how to keep track of the security principle/alias/Issuer that was used to sign the document so it can be used later as the "encryptionUser" going outbound. I know you can set this with a properties file, but I need the "encryptionUser" to be set based off of the incoming request (ie. I will have many clients with different keys).
WS Security - How do I stop a man in the middle?
Hello, I am testing CXF 2.0.3 incubator. I have a "java first / spring" working example of both the request and response using WSS4J Timestamp and Signature. I was wondering if anyone has a suggestion on how to prevent a "man in the middle" from replaying the request (if he does this before the Timestamp expires)? **I can't verify his IP address because he will be coming through a firewall. I do plan on encrypting the data and that would probably make this a non-issue, but I am still having issues trying to get encryption to work. Any suggestions would be appreciated.
Re: wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3 incubator
WSS4J actually has a bug logged on this point. See
http://issues.apache.org/jira/browse/WSS-70 .
The question now is - should CXF fix this or should all users of CXF be
aware of the need to check the actions size yourself?
[EMAIL PROTECTED]
01/16/2008 02:20 PM
Please respond to
cxf-user@incubator.apache.org
To
cxf-user@incubator.apache.org
cc
Subject
Re: wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3
incubator
More info.
Looking at the latest wss4j code (1.5.3), the routine ignores the fact
that the wsse:Security is empty and falls out indicating that all is well.
They have the code to catch this hole commented out for some reason.
protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
int resultActions = wsResult.size();
int size = actions.size();
// if (size != resultActions) {
// throw new AxisFault(
// "WSDoAllReceiver: security processing failed (actions number
// mismatch)");
// }
int ai = 0;
for (int i = 0; i < resultActions; i++) {
final Integer actInt = (Integer) ((WSSecurityEngineResult)
wsResult
.get(i)).get(WSSecurityEngineResult.TAG_ACTION);
int act = actInt.intValue();
if (act == WSConstants.SC || act == WSConstants.BST) {
continue;
}
if (ai >= size || ((Integer) actions.get(ai++)).intValue() !=
act) {
return false;
}
}
return true;
}
[EMAIL PROTECTED]
01/16/2008 01:29 PM
Please respond to
cxf-user@incubator.apache.org
To
cxf-user@incubator.apache.org
cc
Subject
wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3
incubator
Hello,
I'm not sure if this is an issue or lack of correct configuration on my
part.
I found that it is real easy to bypass the security checks (UsernameToken,
Timestamp, and/or Signature) for the WS Security settings.
All you have to do is setup the client request to pass a
tag as empty or with garbage in it and the service side will ignore the
fact that any of those actions are required.
Here is an example request that my service method will answer even though
it is suppose to require a Timestamp and a Signature action in the WS
Security setup.
http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
"
soap:mustUnderstand="1">
leave blank or pass garbage and security is bypassed
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
wsu:Id="id-23632030">
http://spring.demo/";>
Joe
Below is my CXF Servlet Spring beans configuration.
Am I missing something to tell WS Security that the actions are mandatory?
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
passwordCallbackRef
Re: wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3 incubator
More info.
Looking at the latest wss4j code (1.5.3), the routine ignores the fact
that the wsse:Security is empty and falls out indicating that all is well.
They have the code to catch this hole commented out for some reason.
protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
int resultActions = wsResult.size();
int size = actions.size();
// if (size != resultActions) {
// throw new AxisFault(
// "WSDoAllReceiver: security processing failed (actions number
// mismatch)");
// }
int ai = 0;
for (int i = 0; i < resultActions; i++) {
final Integer actInt = (Integer) ((WSSecurityEngineResult)
wsResult
.get(i)).get(WSSecurityEngineResult.TAG_ACTION);
int act = actInt.intValue();
if (act == WSConstants.SC || act == WSConstants.BST) {
continue;
}
if (ai >= size || ((Integer) actions.get(ai++)).intValue() !=
act) {
return false;
}
}
return true;
}
[EMAIL PROTECTED]
01/16/2008 01:29 PM
Please respond to
cxf-user@incubator.apache.org
To
cxf-user@incubator.apache.org
cc
Subject
wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3
incubator
Hello,
I'm not sure if this is an issue or lack of correct configuration on my
part.
I found that it is real easy to bypass the security checks (UsernameToken,
Timestamp, and/or Signature) for the WS Security settings.
All you have to do is setup the client request to pass a
tag as empty or with garbage in it and the service side will ignore the
fact that any of those actions are required.
Here is an example request that my service method will answer even though
it is suppose to require a Timestamp and a Signature action in the WS
Security setup.
http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
"
soap:mustUnderstand="1">
leave blank or pass garbage and security is bypassed
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"
wsu:Id="id-23632030">
http://spring.demo/";>
Joe
Below is my CXF Servlet Spring beans configuration.
Am I missing something to tell WS Security that the actions are mandatory?
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
passwordCallbackRef
wss4jInConfiguration - Security can be bypassed by client in CXF 2.0.3 incubator
Hello, I'm not sure if this is an issue or lack of correct configuration on my part. I found that it is real easy to bypass the security checks (UsernameToken, Timestamp, and/or Signature) for the WS Security settings. All you have to do is setup the client request to pass a tag as empty or with garbage in it and the service side will ignore the fact that any of those actions are required. Here is an example request that my service method will answer even though it is suppose to require a Timestamp and a Signature action in the WS Security setup. http://schemas.xmlsoap.org/soap/envelope/";> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; soap:mustUnderstand="1"> leave blank or pass garbage and security is bypassed http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="id-23632030"> http://spring.demo/";> Joe Below is my CXF Servlet Spring beans configuration. Am I missing something to tell WS Security that the actions are mandatory? http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:jaxws="http://cxf.apache.org/jaxws"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> passwordCallbackRef
