users@glassfish.java.net

Re: [Fwd: [Fwd: Using auth-recipient throws SOAP exception]]

From: <glassfish_at_javadesktop.org>
Date: Thu, 08 Mar 2007 20:30:18 PST

More info provided inline below:

> Hi,
> In this case, most probably, the port-component-name
> or endpoint-address-uri
> is not set correctly in sun-ejb-jar.xml
> This will cause the message-security-binding not to
> take effect.
> You may like to double check that the xml elements
> are correct.
> Thanks.
> Shing Wai Chan

If this was the case, then how would Senario 2 work correctly? In Senario 2, I still have default security policy set to auth-sender="content" and auth-recipient="after-content". I specify message security in sun-ejb-jar.xml to be auth-sender="content" only to override policy to be signed only. I send the message without encryption and it all works. When I change to auth-sender="content" auth-recipient="after-content", and send message unencrypted I get error on server saying that it expected message to be excrypted. If I encrypt the message, I get the SOAP error. So the message-security-binding is being applied.

> umar Jayanti wrote:
> > Hi,
> >
> > Please see my comments at the End....
> >> Subject:
> >> Using auth-recipient throws SOAP exception
> >> From:
> >> glassfish_at_javadesktop.org
> >> Date:
> >> Wed, 07 Mar 2007 16:45:41 -0800 (PST)
> >> To:
> >> users_at_glassfish.dev.java.net
> >>
> >> To:
> >> users_at_glassfish.dev.java.net
> >>
> >>
> >> I am able to deploy my EJB with only a
> sun-ejb-jar.xml descriptor. The glassfish container
> generates the webservices.xml and ejb-jar.xml, and
> updates the sun-ejb-jar.xml file passed in.
> >>
> >> This works somewhat:
> >>
> >> Here are the scenarios:
> >>
> >> 1) Default security provider (No sun-ejb-jar.xml
> provided upon deployment):
> >>
> >> Request policy: auth-source="content"
> auth-recipient="after-content"
> >> Client signs and then encrypts message, all works
> fine.
> >>
> >> 2) Specify provider and request protection in
> sun-ejb-jar.xml to be signature based:
> >>
> >> Request policy: auth-source="content" defined in
> <message-security>
> >> Client signs message
> >>
> >> All works fine.
> >>
> >> 3) Specify provider and request protection in
> sun-ejb-jar.xml to be signature and encrypted.
> (Should be same as Scenario one).
> >>
> >> Request policy: auth-source="content"
> auth-recipient="after-content" defined in
> <message-security>
> >> Client signs and then encrypts message.
> >>
> >> The server throws the following exception:
> >>
> [#|2007-03-07T17:30:37.895-0700|SEVERE|sun-appserver-p
> e9.0|javax.enterprise.resource.webservices.jaxws.serve
> r.soapmd|_ThreadID=12;_ThreadName=httpWorkerThread-808
> 0-1;_RequestID=eb686a92-f5a7-4a24-a83f-fbffeed3dd4d;|E
> rror in decoding SOAP Message
> >> Error in decoding SOAP Message
> >> at
> com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.toI
> nternalMessage(SOAPXMLDecoder.java:89)
> >> at
> com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatc
> her.toMessageInfo(SOAPMessageDispatcher.java:187)
> >> at
> com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatc
> her$SoapInvoker.invoke(SOAPMessageDispatcher.java:571)
> >> at
> com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatc
> her.receive(SOAPMessageDispatcher.java:145)
> >> at com.sun.xml.ws.server.Tie.handle(Tie.java:88)
> >> at
> com.sun.enterprise.webservice.Ejb3MessageDispatcher.ha
> ndlePost(Ejb3MessageDispatcher.java:160)
> >> at
> com.sun.enterprise.webservice.Ejb3MessageDispatcher.in
> voke(Ejb3MessageDispatcher.java:89)
> >> at
> com.sun.enterprise.webservice.EjbWebServiceServlet.dis
> patchToEjbEndpoint(EjbWebServiceServlet.java:178)
> >> at
> com.sun.enterprise.webservice.EjbWebServiceServlet.ser
> vice(EjbWebServiceServlet.java:109)
> >> at
> javax.servlet.http.HttpServlet.service(HttpServlet.jav
> a:820)
> >> at
> com.sun.enterprise.web.AdHocContextValve.invoke(AdHocC
> ontextValve.java:100)
> >> at
> org.apache.catalina.core.StandardPipeline.doInvoke(Sta
> ndardPipeline.java:566)
> >> at
> org.apache.catalina.core.StandardPipeline.invoke(Stand
> ardPipeline.java:536)
> >> at
> com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.
> java:71)
> >> at
> org.apache.catalina.core.StandardHostValve.invoke(Stan
> dardHostValve.java:182)
> >> at
> org.apache.catalina.core.StandardPipeline.doInvoke(Sta
> ndardPipeline.java:566)
> >> at
> com.sun.enterprise.web.VirtualServerPipeline.invoke(Vi
> rtualServerPipeline.java:120)
> >> at
> org.apache.catalina.core.ContainerBase.invoke(Containe
> rBase.java:939)
> >> at
> org.apache.catalina.core.StandardEngineValve.invoke(St
> andardEngineValve.java:137)
> >> at
> org.apache.catalina.core.StandardPipeline.doInvoke(Sta
> ndardPipeline.java:566)
> >> at
> org.apache.catalina.core.StandardPipeline.invoke(Stand
> ardPipeline.java:536)
> >> at
> org.apache.catalina.core.ContainerBase.invoke(Containe
> rBase.java:939)
> >> at
> org.apache.coyote.tomcat5.CoyoteAdapter.service(Coyote
> Adapter.java:231)
> >> at
> com.sun.enterprise.web.connector.grizzly.ProcessorTask
> .invokeAdapter(ProcessorTask.java:667)
> >> at
> com.sun.enterprise.web.connector.grizzly.ProcessorTask
> .processNonBlocked(ProcessorTask.java:574)
> >> at
> com.sun.enterprise.web.connector.grizzly.ProcessorTask
> .process(ProcessorTask.java:844)
> >> at
> com.sun.enterprise.web.connector.grizzly.ReadTask.exec
> uteProcessorTask(ReadTask.java:287)
> >> at
> com.sun.enterprise.web.connector.grizzly.ReadTask.doTa
> sk(ReadTask.java:212)
> >> at
> com.sun.enterprise.web.connector.grizzly.TaskBase.run(
> TaskBase.java:252)
> >> at
> com.sun.enterprise.web.connector.grizzly.WorkerThread.
> run(WorkerThread.java:75)
> >> Caused by: javax.xml.ws.soap.SOAPFaultException:
> Cannot find the dispatch method
> >> at
> com.sun.xml.ws.encoding.soap.SOAPDecoder.raiseFault(SO
> APDecoder.java:674)
> >> at
> com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.dec
> odeDispatchMethod(SOAPXMLDecoder.java:152)
> >> at
> com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeBodyCon
> tent(SOAPDecoder.java:337)
> >> at
> com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeBody(SO
> APDecoder.java:327)
> >> at
> com.sun.xml.ws.encoding.soap.SOAPDecoder.decodeEnvelop
> e(SOAPDecoder.java:250)
> >> at
> com.sun.xml.ws.encoding.soap.server.SOAPXMLDecoder.toI
> nternalMessage(SOAPXMLDecoder.java:81)
> >> ... 29 more
> >>
> >>
> >> Please note that the client is the same for
> Scenario 1 and 3, yet the outcome is greatly
> different.
> > The root cause in this case is :
> > Caused by: javax.xml.ws.soap.SOAPFaultException:
> Cannot find the dispatch method
> >
> > Which means somehow Security was never run on the
> Incoming Message on the Server, which left the
> Message in ecncrypted form, and then the runtime
> tried to find out from the encrypted payload which
> method it should dispatch the request to and
> failed....
> >

> > This is a common error that we encounter when
> Client is Secured and Service is Non-Secure (Security
> is not enabled for the Service). Just guessing
> whether this is the case, because if there was some
> security bug then we would have seen other kind of
> exceptions indicating unable to decrypt of unable to
> verify signature etc.
> >

Security is being called. If I do not encrypt my message (only sign it) I get an exception indicating that encryption is expected.


> > Can you give us more clues on the Service settings
> in this case.
> >
> > Ron, Shing-Wai : In the stack-trace shown above, i
> do not see either the SystemHandlerDelegate nor the
> CommonServerSecurityPipe in picture and this is the
> reason why i am saying the security runtime did not
> kick in for the incoming message. The encrypted
> message was directly given to JAXWS for dispatch and
> it failed as expected.
> >

Does the security work differently when using message-security-binding rather than the container level security?
  
> >> In Scenario 2, the client is the same, yet it
> doesn't encrypt the message.
> >>
> >>
> > Yes this the expected behavior, when you set
> auth-source=content then
> > the message is only Signed (and not encrypted)
> >

This works as expected and documented, which is why I am confused.

> > regards,
> > kumar
> >> Also, I did try manually change the generated
> descriptor, rather than passing in sun-ejb-jar.xml.
> This did not work either. same error.
> >>
> >> Thanks for any help.
> >> [Message sent by forum member 'fefland' (fefland)]
> >>
> >>
> http://forums.java.net/jive/thread.jspa?messageID=2067
> 70
> >>
> >>

One last comment. I am using document-literal binding and using xwss to secure client. Is there any reason that would cause a problem? Also, I can provide a jar containing my project if you want to take a look.



> ------------------------------------------------------
> ---------------
> >> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> >> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> >>
> >>
> >
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
[Message sent by forum member 'fefland' (fefland)]

http://forums.java.net/jive/thread.jspa?messageID=207047