JAX-WS user data constraint cannot be set via server.xml

[UlrichLohrmann]

Open Liberty Version: Open Liberty 21.0.0.9 (wlp-1.0.56.cl210920210824-2341) wlp.install.dir = D:/Programme/openLiberty/openLiberty-JAXWSDemo/wlp/ java.home = D:\tools\jdk\w2k\AdoptOpenJDK-11\11.0.10.9-openj9 java.version = 11.0.10 java.runtime = OpenJDK Runtime Environment (11.0.10+9) os = Windows 10 (10.0; amd64) (en_US)

I have an EJB based JAX-WS service and I would like to ensure that access to the service is via TLS.

According to documentation the user data contstraint of a JAX-WS web service can be set in server.xml using enterpriseApplication > webservices-bnd > http-publishing > webservice-security > security-constraint > user-data-constraint.

Example:

<enterpriseApplication id="..." location="..." name="...">
        <webservices-bnd moduleName="...">
            <http-publishing context-root="service" id="...">
                <webservice-security>
                    <login-config/>
                    <!-- Zugriff ueber SSL erzwingen -->
                    <security-constraint>
                        <web-resource-collection>
                            <web-resource-name>JAXWSDemoEJB</web-resource-name>
                            <http-method>GET</http-method>
                            <http-method>POST</http-method>
                            <http-method>PUT</http-method>
                            <http-method>HEAD</http-method>
                            <http-method>TRACE</http-method>
                            <http-method>DELETE</http-method>
                            <http-method>OPTIONS</http-method>
                            <url-pattern>/service/*</url-pattern>
                        </web-resource-collection>
                        <user-data-constraint>
                            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
                        </user-data-constraint>
                    </security-constraint>
                </webservice-security>
            </http-publishing>
        </webservices-bnd>
</enterpriseApplication>

Using this configuration the following error message is displayed during startup:

[11/12/21, 11:36:56:876 CET] 00000032 com.ibm.ws.config.xml.internal.ConfigEvaluator               E CWWKG0075E: The value CONFIDENTIAL is not valid for attribute transport-guarantee of configuration element enterpriseApplication. The validation message was: Value "CONFIDENTIAL" is not a number..

If I put the webservices-bnd configuration into META-INF/ibm-ws-bnd.xml everything works fine.

[neuwerk]

@UlrichLohrmann I really appreciate you taking the time to open this issue and bringing it to our attention. I'm going to take a look at our config and see if I can spot a reason for the mismatch. I'll keep you posted if I find a cause/solution.

[neuwerk]

@UlrichLohrmann so I did some digging, and it looks like the metadata for the server.xml config expects an integer value (as I'm sure you've guessed by the failure message). Where the ibm-ws-bnd.xml config expects one of three possible strings: NONE, INTEGRAL, CONFIDENTIAL, the server.xml transport-guarantee element expects one of three integer values: 0, 1, 2. These three integer values map to the possible string values in ibm-ws-bnd.xml like this:

0 = NONE 1 = INTEGRAL 2 = CONFIDENTIAL

So for your use case, I'd suggest you change the value of CONFIDENTIAL to 2 and it should work. Can you try that and let me know if it resolves the failure your hitting?

[tbitonti]

Note: Putting in '2' is alright only as a temporary work-around. If the XML text were subsequently copied into the application, a different exception would occur. The correct fix for this is for the parsing code to correctly handle the value as a string value.

[UlrichLohrmann]

@neuwerk Thank you for keeping me informed. I tried to use the numeric value 2 instead of CONFIDENTIAL in server.xml and it worked as expected. If this will be fixed is it possible to post the Open Liberty version that contains the fix?

[neuwerk]

@UlrichLohrmann apologizes for the delay getting back to you, but yes, if it is fixed we can link the PR and give a Open-Liberty release that it goes into.