Skip to main content

WSIT client policy error when receiving a SOAPFault

7 replies [Last post]
montebove
Offline
Joined: 2008-07-17
Points: 0

When a Metro/WSIT client of a service requiring WSS XML Signature with a server policy like:

...

...

receives, instead of the expected response, a Fault (ie: caused by a RuntimeException in the server code) like :
...

S:Serverthis is an exceptionthis is an exception
..

even if the Body message is signed, according to the policy, I get this error:

WSSTUBE0025: Error in Verifying Security in the Inbound Message.
com.sun.xml.wss.impl.PolicyViolationException: ERROR: Policy for the service could not be obtained
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:114)
javax.xml.ws.WebServiceException: WSSTUBE0025: Error in Verifying Security in the Inbound Message.
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.createMessage(SecurityRecipient.java:985)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:410)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:232)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:338)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:486)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:639)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:405)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:338)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:639)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at $Proxy128.add(Unknown Source)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at org.me.calculator.client.servlet.ClientServlet.processRequest(ClientServlet.java:58)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at org.me.calculator.client.servlet.ClientServlet.doGet(ClientServlet.java:92)
at $Proxy128.add(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at org.me.calculator.client.servlet.ClientServlet.processRequest(ClientServlet.java:58)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.me.calculator.client.servlet.ClientServlet.doGet(ClientServlet.java:92)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at java.lang.Thread.run(Thread.java:619)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
Caused by: javax.xml.ws.soap.SOAPFaultException: ERROR: Policy for the service could not be obtained
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getSOAPFaultException(SecurityTubeBase.java:725)
at java.lang.Thread.run(Thread.java:619)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getSOAPFaultException(SecurityTubeBase.java:743)
...

Any idea how to avoid this error?

Thanks

Luciano

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
adrianboimvaser
Offline
Joined: 2011-09-16
Points: 0

Hi Luciano,

I ran into the same problem. Have you found a sollution yet?

Thanks.

Adrián

montebove
Offline
Joined: 2008-07-17
Points: 0

I haven't been working on Metro/WSIT since last year, but I think the problem is still there.

Let me know if you decide to open a bug here java.net/jira/browse/WSIT

Luciano

montebove
Offline
Joined: 2008-07-17
Points: 0

I want to clarify that the problem exists only for unchecked Exception like RuntimeException or Exception not declared as a Fault in the WSDL.
If for example in WSDL I declared:

[i]




...


...




[/i]

the client apply the policy for any Exception from the server, verify the signature and I can access the SOAPFault.
But if the server generates an unchecked exception and so a not declared SOAPFault the client can't obtain the policy.

Luciano

Glen Mazza

I'm not certain what the problem is here. These are unplanned/unexpected
exceptions, things you can't be expected to code for cleanly client-side.
If the SOAP client is returning a policy failure error message that means
it's doing its job, namely looking for the policy before anything else, and
failing when it does not receive it, regardless of why it didn't receive it.

Also, these policy failures are very rare, except when you get a Runtime
Exception or undeclared exception as you write, so the fact that you're
getting a policy exception can perhaps be sufficiently taken to mean you
have a runtime exception, and handled client-side as such.

Glen

metro-3 wrote:
>
> I want to clarify that the problem exists only for unchecked Exception
> like RuntimeException or Exception not declared as a Fault in the WSDL.
> If for example in WSDL I declared:
>
> [i]
>
>
>

>

> ...
>
>
>

> ...
>
> > message="tns:add"/>
> > message="tns:addResponse"/>
> > wsam:Action="http://calculator.me.org/CalculatorWS/add/Fault/Exception"/>
>
[/i]
>
> the client apply the policy for any Exception from the server, verify the
> signature and I can access the SOAPFault.
> But if the server generates an unchecked exception and so a not declared
> SOAPFault the client can't obtain the policy.
>

--
View this message in context: http://old.nabble.com/WSIT-client-policy-error-when-receiving-a-SOAPFaul...
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

montebove
Offline
Joined: 2008-07-17
Points: 0

The problem is that I have no control of server-side code and WSDL and my application is a sort of "intermediary" that should add WS-Security (SAML Token Profile in particular) near transparently to clients and servers (a sort of XML Gateway/Firewall).
So the "real" client should ideally continue to receive any SOAP Fault from the "real" server as it's the case without my "intermediary".
What I can't understand is why WSIT can't apply on the response the policy it already loaded for creating the request.
I know is not an "ideal" way of working with SOAPFaults, but many times they are not declared in the WSDL at all:
http://one-size-doesnt-fit-all.blogspot.com/2009/05/jax-ws-throwing-gene...

and if my "intermediary" is trasforming faults in policy read error it would be too intrusive.

Any idea of how to workaround this problem?

Luciano

>I'm not certain what the problem is here. These are unplanned/unexpected
>exceptions, things you can't be expected to code for cleanly client-side.
>If the SOAP client is returning a policy failure error message that means
>it's doing its job, namely looking for the policy before anything else, and
>failing when it does not receive it, regardless of why it didn't receive it.

>Also, these policy failures are very rare, except when you get a Runtime
>Exception or undeclared exception as you write, so the fact that you're
>getting a policy exception can perhaps be sufficiently taken to mean you
>have a runtime exception, and handled client-side as such.

>Glen

bdaye42
Offline
Joined: 2010-03-29
Points: 0

As you mentioned, executing the expected use case causes no problems. When the normal use case errors out, does it still supply a ws-security header? If so, it appears that unchecked exceptions bypass server-side policy decoration, causing the inbound policy verification to fail.

You have created a security policy that leverages an asymmetric binding. Consequently, Metro is looking for the security token reference from the server on the client side upon receipt

montebove
Offline
Joined: 2008-07-17
Points: 0

[i]> When the normal use case errors
> out, does it still supply a ws-security header? If
> so, it appears that unchecked exceptions bypass
> server-side policy decoration, causing the inbound
> policy verification to fail.[/i]

Probably my description of the problem wasn't clear: the unchecked exception DOESN'T bypass server-side policy and at the wire level the message received from the client containts a proper ws-security header with a correctly signed SOAP fault.

[i]> ..., Metro is looking
> for the security token reference from the server on
> the client side upon receipt[/i]

A I wrote few lines above the token is there and right, but the WSIT client can't find the policy (ie: verify the sign) to apply.

Luciano