[JBossWS] - Re: MTOM + WS Security = problem
by mrostan
Hi all.
We've continued testing MTOM+WS-Security Signature, we need interoperation with Microsoft clients, so swaRef is not an option and we need MTOM and signatures working well.
We have found the following problems:
1) On the server side:
1.a) The WS-Security handlers are not invoked, to solve this change the protocol-bindings in the endpoint-config:
| <endpoint-config>
| <config-name>MTOM WSSecurity Endpoint</config-name>
| <post-handler-chains>
| <javaee:handler-chain>
| <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>
| <javaee:handler>
| <javaee:handler-name>WSSecurity Handler</javaee:handler-name>
| <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class>
| </javaee:handler>
| </javaee:handler-chain>
| </post-handler-chains>
| </endpoint-config>
|
and change the endpoint config on the service implementation:
| @BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING)
| @EndpointConfig(configName = "MTOM WSSecurity Endpoint")
|
1.b) We always receive "Signature is invalid" error, we've found that the replacement of the xop:Include elements to the base64 representation was not made in deep.
We've modifed SOAPFactoryImpl.createElement to invoke XOPContext.inlineXOPData when an xop:Include element is found.
1.c) When the replacement of xop:Include with the base64 representation occurs (see XOPContext.replaceXOPInclude) a content-type attribute is added to the parent element.
This addition breaks the signature, that attribute was not present on the client side, so the signature is still invalid.
We have modified the usage of an attribute with the usage of userData in the node.
The problem here is that NodeImpl does not support the user data, so he have added that support.
Right now, after 1.a 1.b and 1.c we have the signature verification working (testing with a message generated and signed manually, with some help of soapUI).
The next problem:
2) On the client side
2.a) First of all, on the client side the endpoint config must be modified also (to get the ws-security handlers running):
| <client-config>
| <config-name>MTOM WSSecurity Client</config-name>
| <post-handler-chains>
| <javaee:handler-chain>
| <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>
| <javaee:handler>
| <javaee:handler-name>WSSecurityHandlerOutbound</javaee:handler-name>
| <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerClient</javaee:handler-class>
| </javaee:handler>
| </javaee:handler-chain>
| </post-handler-chains>
|
and referenced from the client code:
| ((StubExt)port).setConfigName("MTOM WSSecurity Client");
|
2.b) The message is sent with the binary data inline, and not as an attachment, we need attachments and not base64 encoding.
We have a solution to this problem, but I believe it should be reviewed carefully.
The solution is to invoke
| XOPContext.visitAndRestoreXOPData();
|
after the handlers execution (this is done on the JAXRPC client but not in JAXWS). I have modified CommonClient and DispatchImpl to make this invocation.
Finally, we have a patch with the modifications on 1.b, 1.c and 2.b to the current trunk.
I will upload it to a JIRA issue if the JBossWS team accepts this solution.
Regards,
Martin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132257#4132257
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132257
16 years, 2 months
[JBossWS] - Re: WSSE UsernameToken without HTTP basic auth?
by alessio.soldano＠jboss.com
"alessio.soldano(a)jboss.com" wrote : I did a bit of tests and investigation..
|
| "mageshbk(a)jboss.com" wrote : The Username token sent in the SOAP Message is the one used by the endpoint server/stack to authenticate the user who is performing this request. This is called MessageLevel Security as defined by UsernameToken profile. If you see, Servlet endpoints can be configured with only basic or digest as per the specs of their deployment model. So setting AUTH_TYPE_WSSE is not and will not be applicable to the servlet deployment model unless you write your own customized implementation for it.
|
| mikaeljl, in other words this means you can easily and successfully use the wsse username token profile without basic authentication through EJB3 endpoints.
| I did this way:
|
| | @WebService(
| | wsdlLocation = "META-INF/wsdl/WsSecurity10.wsdl",
| | serviceName = "PingService10",
| | name = "IPingService",
| | targetNamespace = "http://InteropBaseAddress/interop",
| | endpointInterface = "org.jboss.test.ws.interop.nov2007.wsse.IPingService",
| | portName = "UserNameOverTransport_IPingService")
| | @EndpointConfig(configName = "Standard WSSecurity Endpoint")
| | @Stateless
| | @SecurityDomain("JBossWS")
| | @WebContext(contextRoot="/nov2007/wsseUsernameTokenHTTPS", urlPattern="/endpoint")
| | public class UsernameTokenHTTPSTestService extends TestService implements IPingService {
| | ...
| | }
| |
| please note, no authMethod and transportGuarantee in the @WebContext.
|
| On the client side:
|
| | ((BindingProvider)port).getRequestContext().put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE);
| | ((BindingProvider)port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "kermit");
| | ((BindingProvider)port).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "thefrog");
| |
| This prevents the stack from using the basic auth and set the user/pwd in the context so that they can be put in the Username token. The principal is set and can be retrieved. Using the wrong user/pwd couple causes an authentication failure due to a javax.ejb.EJBAccessException.
| Of course you need to set client wsse config the right way:
|
| | <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">
| | <config>
| | <username/>
| | <timestamp ttl="300"/>
| | </config>
| | </jboss-ws-security>
| |
Btw I've just added a use case test for the JBWS-1991 issue; it basically use the above described solution.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132141#4132141
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132141
16 years, 2 months