[JBossWS] - Re: Stop enforcing parameter names?
by bcowan
"thomas.diesler(a)jboss.com" wrote : The question is, whether the incomming message conforms to the abstract contract published by the endpoint. If the message is invalid with that respect it simply is invalid
At this point we're much more concerned about consistency. Updating to a newer server version has invalidated several thousand clients because the server has changed the way it validates the messages. Granted that those clients don't conform 100% to the published WSDL, but the tools at the time (including JBoss) ignored parameter names so it has never been an issue. Since the WSDL specifies the type and order of the parameters, validation of the actual name wasn't (and perhaps isn't) required.
We just need the current version of the JBoss web service stack to handle messages in compatible manner with the prior version. Judging by your response, it sounds like there is no such compatibility option.
Regards,
Bruce
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051420#4051420
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051420
18 years, 3 months
[JBossWS] - JBossWS with JBoss 4.2.0 and Axis 1.4 don't work with WSSecu
by bigdaddy66
Hi,
i want to setup a testbed to communicate secure between JBoss 4.2.0 and Axis 1.4 with WSS4J 1.5.2.
I already setup an WSFacade (EJB2.1) with a simple Add-Method to sum up two Integer. The Method works (the whole WSFacade has more Methods that are all already used and working fine.
Now i want to setup WSSecurity with WSS4J. No Authentication - only Signing and Encryption between the Server (JBoss) and the Client (Axis).
I developed a simple standalone J2SE-Application which successful call the add-method and get the result - all fine without signing etc.
Now with signing i receive following error-message in the jboss-console:
anonymous wrote :
| 16:51:27,394 ERROR [WSSecurityDispatcher] Internal error occured handling inbound message:
| org.jboss.ws.extensions.security.SecurityTokenUnavailableException: Could not locate certificate by issuer and serial number
| at org.jboss.ws.extensions.security.KeyResolver.resolveX509IssuerSerial(KeyResolver.java:122)
| at org.jboss.ws.extensions.security.KeyResolver.resolve(KeyResolver.java:92)
| at org.jboss.ws.extensions.security.KeyResolver.resolveCertificate(KeyResolver.java:129)
| at org.jboss.ws.extensions.security.KeyResolver.resolvePublicKey(KeyResolver.java:139)
| at org.jboss.ws.extensions.security.KeyResolver.resolvePublicKey(KeyResolver.java:159)
| at org.jboss.ws.extensions.security.element.Signature.(Signature.java:56)
| at org.jboss.ws.extensions.security.element.SecurityHeader.(SecurityHeader.java:87)
| at org.jboss.ws.extensions.security.SecurityDecoder.decode(SecurityDecoder.java:182)
| at org.jboss.ws.extensions.security.WSSecurityDispatcher.handleInbound(WSSecurityDispatcher.java:145)
| at org.jboss.ws.extensions.security.jaxrpc.WSSecurityHandler.handleInboundSecurity(WSSecurityHandler.java:66)
| at org.jboss.ws.extensions.security.jaxrpc.WSSecurityHandlerInbound.handleRequest(WSSecurityHandlerInbound.java:42)
| at org.jboss.ws.core.jaxrpc.handler.HandlerWrapper.handleRequest(HandlerWrapper.java:121)
| at org.jboss.ws.core.jaxrpc.handler.HandlerChainBaseImpl.handleRequestInternal(HandlerChainBaseImpl.java:291)
| at org.jboss.ws.core.jaxrpc.handler.HandlerChainBaseImpl.handleRequest(HandlerChainBaseImpl.java:251)
| at org.jboss.ws.core.jaxrpc.handler.ServerHandlerChain.handleRequest(ServerHandlerChain.java:54)
| at org.jboss.ws.core.jaxrpc.handler.HandlerDelegateJAXRPC.callRequestHandlerChain(HandlerDelegateJAXRPC.java:108)
| at org.jboss.ws.integration.jboss42.ServiceEndpointInvokerEJB21$HandlerCallback.callRequestHandlerChain(ServiceEndpointInvokerEJB21.java:248)
| at org.jboss.ws.integration.jboss42.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:83)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
| at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
| at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
| at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
| at org.jboss.ejb.Container.invoke(Container.java:960)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.ws.integration.jboss42.ServiceEndpointInvokerEJB21.invokeServiceEndpointInstance(ServiceEndpointInvokerEJB21.java:189)
| at org.jboss.ws.core.server.AbstractServiceEndpointInvoker.invoke(AbstractServiceEndpointInvoker.java:207)
| at org.jboss.ws.core.server.ServiceEndpoint.processRequest(ServiceEndpoint.java:212)
| at org.jboss.ws.core.server.ServiceEndpointManager.processRequest(ServiceEndpointManager.java:448)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(AbstractServiceEndpointServlet.java:114)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
| at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(AbstractServiceEndpointServlet.java:75)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
|
I can't find the errormessage in this forum or the internet (except the sourcecode of jboss)
The error comes clear to the client as SOAP Fault:
anonymous wrote :
| Exception in thread "main" AxisFault
| faultCode: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}SecurityTokenUnavailable
| faultSubcode:
| faultString: Could not locate certificate by issuer and serial number
| faultActor:
| faultNode:
| faultDetail:
| {http://xml.apache.org/axis/}stackTrace:Could not locate certificate by issuer and serial number
| .... CUT
|
What can happend?
Now to my little client:
| public static void main(String[] args) throws Exception {
| URL url = new URL(
| "http://127.0.0.1:8080/WSFacadeSessionService/WSFacadeSession?wsdl");
|
| QName qname = new QName("http://model.nhb.cerebral.de",
| "WSFacadeService");
|
| ServiceFactory factory = ServiceFactory.newInstance();
| Service service = factory.createService(url, qname);
|
| WSFacadeEndpoint endpoint = (WSFacadeEndpoint) service
| .getPort(WSFacadeEndpoint.class);
|
| int a = 5;
| int b = 7;
| int sum = endpoint.add(a, b);
|
| System.out.println(a + " + " + b + " = " + sum);
|
| }
|
My PWCallback simple set the password. (Its only a testbed, u can know the stupid passwd :-))
| public void handle(Callback[] callbacks) throws IOException,
| UnsupportedCallbackException {
|
| for (int i = 0; i < callbacks.length; i++) {
| if (callbacks instanceof WSPasswordCallback) {
| WSPasswordCallback pc = (WSPasswordCallback) callbacks;
|
| pc.setPassword("guenthermuh");
|
| } else {
| throw new UnsupportedCallbackException(callbacks,
| "Unrecognized Callback");
| }
| }
| }
|
Now the DDs:
client-config.wsdd:
| <deployment xmlns="http://xml.apache.org/axis/wsdd/"
| xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
| <transport name="http"
| pivot="java:org.apache.axis.transport.http.HTTPSender" />
| <globalConfiguration>
| <requestFlow>
| <handler
| type="java:org.apache.ws.axis.security.WSDoAllSender">
| <parameter name="action" value="Signature" />
| <parameter name="user" value="clientcert" />
| <parameter name="passwordCallbackClass"
| value="PWCallback" />
| <parameter name="signaturePropFile"
| value="crypto.properties" />
| <parameter name="mustUnderstand" value="true" />
| </handler>
| </requestFlow>
| <responseFlow>
| <handler
| type="java:org.apache.ws.axis.security.WSDoAllReceiver">
| <parameter name="action" value="Signature" />
| <parameter name="signaturePropFile"
| value="crypto.properties" />
| </handler>
| </responseFlow>
| </globalConfiguration>
| </deployment>
|
my crypto.properties:
| org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
| org.apache.ws.security.crypto.merlin.keystore.type=jks
| org.apache.ws.security.crypto.merlin.file=client.keystore
| org.apache.ws.security.crypto.merlin.keystore.alias=clientcert
| org.apache.ws.security.crypto.merlin.keystore.password=guenthermuh
| org.apache.ws.security.crypto.merlin.alias.password=guenthermuh
|
To the certificates later.
Now the JBoss-server:
in the webservices.xml in the port-component-block i added this:
| <endpoint-config>
|
| <config-name>Standard Secure Endpoint</config-name>
| <handler-config>
| <handler-chain>
| <handler-chain-name>
| SecureHandlerChain
| </handler-chain-name>
| <handler>
| <handler-name>
| WSSecurityHandlerInbound
| </handler-name>
| <handler-class>
| org.jboss.ws.extensions.security.jaxrpc.WSSecurityHandlerInbound
| </handler-class>
| </handler>
| </handler-chain>
| </handler-config>
| <endpoint-config>
|
my jboss-wsse-server.xml:
| <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://www.jboss.com/ws-security/config
| http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
| <key-store-file>META-INF/wsse.keystore</key-store-file>
| <key-store-password>guenthermuh</key-store-password>
| <trust-store-file>META-INF/wsse.truststore</trust-store-file>
| <trust-store-password>guenthermuh</trust-store-password>
| <config>
| <!-- <timestamp ttl="15" /> -->
| <sign type="x509v1" alias="wsse" />
| <!-- <encrypt type="x509v3" alias="wsse" /> -->
| <requires>
| <signature />
| </requires>
| </config>
| </jboss-ws-security>
|
to "sign type="x509v1" " - the same error exist with x509x3 as type definition
I can post the webservice request when you want.It has the security-header etc.
To the certificates: i generated all with the keytool like the schema described here in the forums.
alice (JBoss) has in his wsse.keystore there own private and public-key (signed) and i imported the public-key from Bob (signed too). the wsse.truststore only has the public-key from alice. (Alias: wsse)
Bob has only a keystore: client.keystore - alias: clientcert.
it included his own private and publickey (signed) and the publickey from alice (signed too).
so, what is wrong? :-)
And does i need the WSSecurityHandlerOutbound for a fullsecure communication?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051413#4051413
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051413
18 years, 3 months
[JBossWS] - Stop enforcing parameter names?
by bcowan
I've recently updated a web service from JBoss 4.0.2 to 4.0.5 with JBossWS 1.2.1, and it's causing problems. The new setup enforces the proper naming of method parameters, instead of just taking them positionally.
Some older clients don't send the proper parameter names. For example, Axis generated clients just call them "in0", "in1", "in2", etc. Whereas the old server happily accepted this, the new one throws a NotFound exception because the WSDL lists them as "String_1", "String_2", and so on.
Is there any way to stop enforcing parameter names? The WSDL specifies the proper order, and this is all we need. It is important so remain compatible with old clients without changing the WSDL.
Thanks,
Bruce
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051378#4051378
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051378
18 years, 3 months
[JBossWS] - Re: SWA / MTOM attachments
by heiko.braun＠jboss.com
Sreedhar, MTOM and SwA are two diffrent things. Both deal with attachments but in different manner. Actually when talking about attachments you'll encounter SwA, SwARef and MTOM/XOP.
SwA has interop issues which SwARef did solve and MTOM relieves the interposed SOAP processors from having to deal with resource consumption while processing messages in transit.
However, looking at your detailed report (thanks, that simplifies things a lot) i can see two things:
anonymous wrote :
| org.jboss.ws.binding.BindingException: Mime type text/xml not allowed for parameter mimepart allowed types are [application/xml]
|
anonymous wrote :
| URL temp = new File("resources/jaxrpc/samples/swa/attach.xml").toURL();
|
See first one states that the endpoint does only accept attachment of the type "application/octet-stream". Looking at your samples code in the second quote, you create a URL to a *.xml file. The JAF API will create a DataHandler instance with the content-type 'text/xml' from that, which then would be submitted.
If you change the client to use the right content-type everything works fine. Please consult the JAF API for further information on this topic.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051323#4051323
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051323
18 years, 3 months