2 Replies Latest reply on Aug 24, 2007 9:54 AM by kimbaltrue

    Is there a workaround for the UsernameToken security header?

    kimbaltrue Newbie

      I'm using 4.2.0.GA with JSR-181 EJB webservices.

      My EBJ's are topped with the following annotations:

      @WebService(name = "InstitutionServices", targetNamespace = "http://tagus.ccf.org/", serviceName = "InstitutionServices")
      @SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
      /*
       * JBOSS specific security annotations
       */
      @SecurityDomain("tagus-domain")
      @WebContext(authMethod="BASIC", transportGuarantee="NONE", secureWSDLAccess=false)
      
      @Stateless(name = "InstitutionServices")
      @Local(InstitutionServices.class)
      @Remote(InstitutionServices.class)
      /*
       * JBOSS Specific
       */
      @RemoteBinding(jndiBinding = "/ejb3/InstitutionServices")
      
      @Interceptors(ServiceMetrics.class)
      @TransactionManagement(TransactionManagementType.BEAN)


      I'm using a Java 6.0 client to generate the request which looks like this:

      <?xml version="1.0" ?>
      <soapenv:Envelope
       xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
       xmlns:ns1="http://tagus.ccf.org/"
       xmlns:xsd="http://www.w3.org/2001/XMLSchema">
       <soapenv:Header>
       <wsse:Security
       xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
       soapenv:mustUnderstand="1">
       <wsse:UsernameToken
       xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
       wsu:Id="XWSSGID-1187016843328-1067189645">
       <wsse:Username>1234/kimbal</wsse:Username>
       <wsse:Password
       Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welch</wsse:Password>
       <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">aNzX50aOu5XC7UYDOXZd7/xh</wsse:Nonce>
       <wsu:Created>2007-08-13T14:54:11.937Z</wsu:Created>
       </wsse:UsernameToken>
       </wsse:Security>
       </soapenv:Header>
       <soapenv:Body>
       <ns1:Ping>
       <ns1:Request>Hello World</ns1:Request>
       </ns1:Ping>
       </soapenv:Body>
      </soapenv:Envelope>



      Everything looks right, but I'm getting the following error:

      11:22:13,593 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
      javax.xml.ws.soap.SOAPFaultException: Unprocessed 'mustUnderstand' header element: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
       at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.getSOAPFaultException(SOAPFaultHelperJAXWS.java:70)
       at org.jboss.ws.core.jaxws.binding.SOAP11BindingJAXWS.throwFaultException(SOAP11BindingJAXWS.java:109)
       at org.jboss.ws.core.CommonSOAP11Binding.verifyUnderstoodHeader(CommonSOAP11Binding.java:87)
       at org.jboss.ws.core.CommonSOAPBinding.checkMustUnderstand(CommonSOAPBinding.java:911)
       at org.jboss.ws.core.server.AbstractServiceEndpointInvoker.invoke(AbstractServiceEndpointInvoker.java:184)
       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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
       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've gone through all the topics on the JBossWS forum that refer to security or unprocessed mustUnderstand headers. I couldn't find a fix or a work around in any of them. After reading some it sounded like JBoss doesn't understand the current security header format. Is there a work around for this? What format is JBoss expecting? I'm willing the code a replacement header that will match what JBoss is expecting if that will work. However, at this point I'm not sure if JBoss is even looking for a security header at all. When using JSR-181 do I need an XML configuration file for a clear text password?

      At this stage I'm even willing to rip the security out if I didn't need the user identification during server processing.