This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1021049 - Can't define SOAPHandlers in JBossWS configuration to handle SOAP Headers with mustUnderstand [NEEDINFO]
Can't define SOAPHandlers in JBossWS configuration to handle SOAP Headers wit...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services (Show other bugs)
6.1.1
Unspecified Unspecified
unspecified Severity unspecified
: CR1
: EAP 6.2.0
Assigned To: Petr Sakař
Rostislav Svoboda
Russell Dickenson
:
Depends On: 1021549 1026992
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 17:08 EDT by Chris Dolphy
Modified: 2014-06-18 03:20 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:19:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jcacek: needinfo? (rdickens)


Attachments (Terms of Use)
testcase (90.00 KB, application/gzip)
2013-10-18 17:15 EDT, Chris Dolphy
no flags Details
Server log with exception (19.71 KB, text/plain)
2013-11-12 08:20 EST, Petr Sakař
no flags Details

  None (edit)
Description Chris Dolphy 2013-10-18 17:08:19 EDT
Description of problem:
Appears to be fixed by https://issues.jboss.org/browse/JBWS-3720

Using org.picketlink.trust.jbossws.handler.SAML2Handler in standalone.xml as post-handler-chain, the following error is thrown processing WS-Security headers:

15:54:58,287 ERROR [com.redhat.gss.sts.StsClient] (http-/127.0.0.1:8080-1) Problem: javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
...
Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.


Version-Release number of selected component (if applicable):
EAP 6.1.1 (Jbossws common 2.1.3)

How reproducible:
easily

Steps to Reproduce:
1.  Deploy picketlink STS quickstart
2.  Configure STS security domain
3.  Configure security domain for web service
4.  Configure web service endpoint config.
5.  Deploy web service using endpoint-config

Actual results:

Soap fault:
      <faultcode>soap:MustUnderstand</faultcode>
      <faultstring>MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.  
   </faultstring>



Expected results:

Expect successful service call with STS authentication


Additional info:


Stack trace:

Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood.
	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84)
	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51)
	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:140)
	at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:71)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:800) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1704)
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1537)
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1445)
	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:660)
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319) [cxf-api-2.6.8.redhat-7.jar:2.6.8.redhat-7]
	at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
	... 18 more
Comment 1 Chris Dolphy 2013-10-18 17:15:53 EDT
Created attachment 813910 [details]
testcase

includes my standalone.xml and a test web service.   See Readme.md.
Comment 3 Petr Sakař 2013-11-08 04:22:20 EST
verification is blocked by BZ 1021049
Comment 5 Petr Sakař 2013-11-11 01:38:49 EST
Verification is blocked by BZ 1026992
Comment 9 Petr Sakař 2013-11-12 08:18:12 EST
verification failed 

verification procedure:

download EAP
download attached testcase

cd /home/development/jbossqe/BZ/BZ1021049/
unzip /home/development/artifacts/jboss-eap-6.2.0.CR1.zip

export JBOSS_HOME=/home/development/jbossqe/BZ/BZ1021049/jboss-eap-6.2
echo JBOSS_HOME=$JBOSS_HOME

$JBOSS_HOME/bin/standalone.sh
$JBOSS_HOME/bin/jboss-cli.sh -c '/system-property=org.jboss.ws.cxf.disableHandlerAuthChecks:add(value=true)'
$JBOSS_HOME/bin/jboss-cli.sh -c ':reload'


$JBOSS_HOME/bin/jboss-cli.sh -c 'shutdown'


vi $JBOSS_HOME/standalone/configuration/standalone.xml
# add picketlink and testcase security domains
# add on line 278 before line with </security-domains>
                <security-domain name="picketlink-sts" cache-type="default">
                    <authentication>
                        <login-module code="UsersRoles" flag="required">
                            <module-option name="usersProperties" value="users.properties"/>
                            <module-option name="rolesProperties" value="roles.properties"/>
                        </login-module>
                    </authentication>
                </security-domain>
                <security-domain name="sts-endpoint" cache-type="default">
                    <authentication>
                        <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule" flag="required" module="org.picketlink">
                            <module-option name="configFile" value="/example-sts-client.properties"/>
                        </login-module>
                    </authentication>
                </security-domain>

#END OF add picketlink and testcase security domains

$JBOSS_HOME/bin/standalone.sh


git clone https://github.com/picketlink2/picketlink-quickstarts
cd picketlink-quickstarts/
git checkout v2.1.6.Final
cd ws-trust/picketlink-sts

mvn clean package

$JBOSS_HOME/bin/jboss-cli.sh -c "deploy target/picketlink-sts-2.1.6.Final-jboss-as7.war"

cd ../../../
tar xvf testcase.tar.gz
cd testcase/sts-client.war

sed -i "s/stsuser/UserA/g" WEB-INF/classes/com/redhat/gss/sts/StsClient.java
sed -i "s/RedHat13#/PassA/g" WEB-INF/classes/com/redhat/gss/sts/StsClient.java

ant clean deploy

curl http://localhost:8080/sts-client/client?name=Kyle
Comment 10 Petr Sakař 2013-11-12 08:20:03 EST
Created attachment 822971 [details]
Server log with exception

attached server log with exception thrown during verification
Comment 11 Alessio Soldano 2013-11-12 16:41:58 EST
This has taken me hours of debugging... to eventually figure out the verification procedure is actually wrong.
Despite containing a jaxws-handlers-server.xml descriptor with the PL handlers declaration, the com.redhat.gss.sts.TestEndpointImpl does not actually uses it. As a matter of fact, the endpoint does not include a @HandlerChain annotation referencing the handler descriptor, while it uses the jbossws api @EndpointConfig annotation, without specifying a configFile in it. In such case, the configuration is to be read from the webservices subsystem in the AS model.
The original bugzilla description here above actually says "4.  Configure web service endpoint config", but that was not included in the verification procedure (I didn't notice it too at first :-/ ). The webservices subsystem in the standalone.xml needs to be modified with something like what follows (not sure about the exact requirements, it's really a PL app configuration):

<endpoint-config name="sts-config">
  <pre-handler-chain name="sts-config-chain" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
    <handler name="SAMLAuth" class="org.picketlink.trust.jbossws.handler.WSAuthenticationHandler"/>
    <handler name="SAMLHandler" class="org.picketlink.trust.jbossws.handler.SAML2Handler"/>
  </pre-handler-chain>
</endpoint-config>

After I did that, I could not reproduce the mustUnderstand header not understood error.

As an additional explanation, the reason for this all is that CXF comes with an interceptor that verifies the headers are actually understood; to achieve that, it scans the current interceptor chain and looks for handlers that are capable of "understanding" headers. In short, that means CXF SOAPHandlerInterceptor instances serving a non-empty JAXWS handler-chain whose handlers return at least an understood header QName. The configuration/verification issue here was preventing an handler chain from being installed in the endpoint, resulting in a interceptor chain without SOAPHandlerInterceptor and hence able to pass the mustUnderstand verification.

To simplify the debugging of situations like this, I'll add a warning message to be printed when a server endpoint configuration is looked up and not found. This is anyway an independent improvement. The bugzilla here should be properly verified regardless of the warning message improvement.
Comment 12 Alessio Soldano 2013-11-12 16:43:30 EST
Of course an equivalent approach (to avoid modifying the webservices subsystem) is to actually add a @HandlerChain annotation in the TestEndpointImpl...
Comment 13 Petr Sakař 2013-11-13 02:06:47 EST
Verified for EAP 6.2.0.CR1

Verification procedure (fixed version from comment#9 - added endpoint config "sts-config" and fixed username and password in WEB-INF/classes/example-sts-client.properties)


cd /home/development/jbossqe/BZ/BZ1021049/
unzip /home/development/artifacts/jboss-eap-6.2.0.CR1.zip

export JBOSS_HOME=/home/development/jbossqe/BZ/BZ1021049/jboss-eap-6.2
echo JBOSS_HOME=$JBOSS_HOME

$JBOSS_HOME/bin/standalone.sh
$JBOSS_HOME/bin/jboss-cli.sh -c '/system-property=org.jboss.ws.cxf.disableHandlerAuthChecks:add(value=true)'
$JBOSS_HOME/bin/jboss-cli.sh -c ':reload'


$JBOSS_HOME/bin/jboss-cli.sh -c 'shutdown'


vi $JBOSS_HOME/standalone/configuration/standalone.xml
# add picketlink and testcase security domains
# add on line 278 before line with </security-domains>
                <security-domain name="picketlink-sts" cache-type="default">
                    <authentication>
                        <login-module code="UsersRoles" flag="required">
                            <module-option name="usersProperties" value="users.properties"/>
                            <module-option name="rolesProperties" value="roles.properties"/>
                        </login-module>
                    </authentication>
                </security-domain>
                <security-domain name="sts-endpoint" cache-type="default">
                    <authentication>
                        <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule" flag="required" module="org.picketlink">
                            <module-option name="configFile" value="/example-sts-client.properties"/>
                        </login-module>
                    </authentication>
                </security-domain>
# add below line ? <subsystem xmlns="urn:jboss:domain:webservices:1.2">

			<endpoint-config name="sts-config">
			  <pre-handler-chain name="sts-config-chain" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
				<handler name="SAMLAuth" class="org.picketlink.trust.jbossws.handler.WSAuthenticationHandler"/>
				<handler name="SAMLHandler" class="org.picketlink.trust.jbossws.handler.SAML2Handler"/>
			  </pre-handler-chain>
			</endpoint-config>
        


#END OF add picketlink and testcase security domains
$JBOSS_HOME/bin/standalone.sh


git clone https://github.com/picketlink2/picketlink-quickstarts
cd picketlink-quickstarts/
git checkout v2.1.6.Final
cd ws-trust/picketlink-sts

mvn clean package

$JBOSS_HOME/bin/jboss-cli.sh -c "deploy target/picketlink-sts-2.1.6.Final-jboss-as7.war"

cd ../../../
tar xvf testcase.tar.gz
cd testcase/sts-client.war
# fix username and password used for picketlink STS authentication
sed -i "s/stsuser/UserA/g" WEB-INF/classes/com/redhat/gss/sts/StsClient.java
sed -i "s/RedHat13#/PassA/g" WEB-INF/classes/com/redhat/gss/sts/StsClient.java

sed -i "s/username=sts/username=UserA/g" WEB-INF/classes/example-sts-client.properties
sed -i "s/RedHat13#/PassA/g" WEB-INF/classes/example-sts-client.properties

ant clean deploy

curl http://localhost:8080/sts-client/client?name=Kyle

Note You need to log in before you can comment on or make changes to this bug.