4 Replies Latest reply on Mar 12, 2008 1:08 PM by squ1rr3l

    webservice <transport-guarantee> CONFIDENTIAL does not work?

    fsilva_vormetric

      Hello,

      I created a webservice using a session bean as endpoint, and allows only SSL communication. In jboss.xml, I specified:


      <ejb-name>myejb</ejb-name>
      <jndi-name>myejbname</jndi-name>
      <port-component>
      <port-component-name>Myname</port-component-name>
      <port-component-uri>/hello/myservice</port-componenturi>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </port-component>


      I then deployed my webservice to jboss and jboss deployed the webservice to https://myserver:8443/hello/myservice. NOtice, it was deployed to the secure SSL port 8443, which is what I wanted.

      But when I try to create a client which connects via the non-secure port http://myserver:8080/hello/myservice... JBOSS allows the request to get through!!

      I thought specifying CONFIDENTIAL in transport-guarantee will force client NON-SSL requests to fail????

        • 1. Re: webservice <transport-guarantee> CONFIDENTIAL does not w
          sappenin

          One would think that if you mark the endpoint to be CONFIDENTIAL, that regular request would not go through.

          However, in the JBossWS user guide, the following statement sticks out to me (Taken from: http://labs.jboss.com/portal/jbossws/user-guide/en/html/secure-ejb.html):


          At last, make sure that your WSDL files point to the right url. Otherwise your webservice client may be redirected to the unsecure HTTP access method. The easiest way is to add "https://" to the SOAP Address entry:


          If simply omitting the "s" in the https:// portion of the url can redirect to the unsecured version of the endpoint, then hitting the unsecured endpoint on port 80 or 8080 seems like it would work, too.

          So, judging from the docs, it seems like the server can decide to still allow the unsecured endpoint? Not sure if this is a feature, or a bug. Maybe someone from JBoss can shed more light on this?

          • 2. Re: webservice <transport-guarantee> CONFIDENTIAL does not w
            fsilva_vormetric

            yes, I wish someone from JBoss would reply. But I've been having difficulty getting replies to my posts. Any ideas on how I can escalate to get a response? thanks.

            • 3. Re: webservice <transport-guarantee> CONFIDENTIAL does not w
              thomas.diesler

              The above does not seem to be true.

              When you deploy an EJB endpoint with

              <port-component>
               <port-component-name>Myname</port-component-name>
               <port-component-uri>/hello/myservice</port-componenturi>
               <transport-guarantee>CONFIDENTIAL</transport-guarantee>
              </port-component>
              


              jbossws generates a web.xml (have a look at the "Server Temp Dir") that uses <transport-guarantee>CONFIDENTIAL</transport-guarantee>

              From then onwards, your endpoint behaves like any other webapp that uses CONFIDENTIAL.


              At last, make sure that your WSDL files point to the right url. Otherwise your webservice client may be redirected to the unsecure HTTP access method.


              This is indeed misleading. It should read


              At last, make sure that the endpoint address in your WSDL file uses a secure protocol.





              • 4. Re: webservice <transport-guarantee> CONFIDENTIAL does not w

                So am I securing the consoles wrong? If I add

                 <security-constraint>
                 <user-data-constraint>
                 <transport-guarantee>CONFIDENTIAL</transport-guarantee>
                 </user-data-constraint>
                 </security-constraint>
                

                to the web.xml files in both /server/prod/deploy/jboss-web.deployer/ROOT.war/WEB-INF and /server/prod/deploy/jmx-console.war/WEB-INF it seems to have no affect. I can still connect to both unsecured on port 8080. https works fine, but I have to specify it, and 8080 is still allowed on both apps.

                Is there something else required?