Skip to main content

Problem with secured SOAP fault

47 replies [Last post]
amason
Offline
Joined: 2007-02-26

Am trying to throw a custom SOAP fault from Java WSIT web service to .NET and getting a NullPointerException. It may be am doing this wrong, but I have attached WSDL, schema for reference. Here's a piece of the error.

SEVERE: WSS1346. Error preparing Symmetric key for Signature
java.lang.NullPointerException:
at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.importNode(Co
reDocumentImpl.java:1478)
at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.importNode(Co
reDocumentImpl.java:1444)
at com.sun.xml.messaging.saaj.soap.SOAPDocumentImpl.importNode(SOAPDocum
entImpl.java:147)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.importNode(SOAPPartImpl.
java:444)
at com.sun.xml.wss.impl.dsig.SignatureProcessor.prepareForSymmetricKeySi
gnature(SignatureProcessor.java:1759)
at com.sun.xml.wss.impl.dsig.SignatureProcessor.sign(SignatureProcessor.
java:373)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java
:452)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.j
ava:412)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:79
)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:249)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityA
nnotator.java:172)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotato
r.java:133)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.secureOutboundMessage(Sec
urityPipeBase.java:313)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ritzmann
Offline
Joined: 2003-06-19

Bug #671 is fixed now on the trunk and should appear in tomorrow's nightly build. We verified that the fix works with mulepic's application.

ashutoshshahi
Offline
Joined: 2006-01-27

Fixed the issue, Faults with IssuedToken are secured now.

amason
Offline
Joined: 2007-02-26

Great! Please indicate what nightly build will definitely have this fix so that we can try it. BTW, in case it makes any difference, we are doing wsdl-first (wsimport) development as opposed to code-first (wsgen).

ashutoshshahi
Offline
Joined: 2006-01-27

> Great! Please indicate what nightly build will
> definitely have this fix so that we can try it.

It should be available in tomorrow's nightly.

> in case it makes any difference, we are doing
> wsdl-first (wsimport) development as opposed to
> code-first (wsgen).

It should not make a difference. Please report if you see some problems

amason
Offline
Joined: 2007-02-26

OK. Downloaded today's nightly build 8/23 and am still seeing unsecured faults which of course WCF/.NET complain about.

Message was edited by: amason

ashutoshshahi
Offline
Joined: 2006-01-27

You mean you tried IssuedToken sample and got unsecured faults? IssuedToken in case of from java should work now. We fixed the NPE that you mentioned about.

Is unsecured faults coming only for from wsdl approach? In that case we will need to look into the problem

amason
Offline
Joined: 2007-02-26

Yes, we are getting unsecured faults. I had actually rearrange WSDL defs and gotten around the NPE, so am not sure if I have your fix or not. The unsecured faults could well be related to WSDL-only, but that's the situation right now. Normal request/response is encrypted but faults are sent unencrypted which .NET then has a problem with.

ashutoshshahi
Offline
Joined: 2006-01-27

Please send across your latest wsdl in that case. I will look into it

ashutoshshahi
Offline
Joined: 2006-01-27

We found the issue. Its a problem with handling of IssuedTokens in case of faults. We will fix it and get back to you.

amason
Offline
Joined: 2007-02-26

That's great! I since have gotten around the NullPointerException by renaming some of the elements in my WSDL (like particularly around the fault and message) and then have gotten to Matt's problem of the fault is thrown but not secured properly (at all). I can verify this situation by enabling WSIT message dump.

mulepic
Offline
Joined: 2007-02-05

I pulled the latest and did not see the issue solved. Then I read the description of the bug and it's pretty clear this isn't fixed and it is going to take a little bit of work.

Thanks

ritzmann
Offline
Joined: 2003-06-19

Yes, we know how to fix the issue now, but it is still going to take a couple of days to implement.

ritzmann
Offline
Joined: 2003-06-19

It should be fixed now. It might still take a day or two until the change shows up in the daily builds.

mulepic
Offline
Joined: 2007-02-05

Hi,

I pulled the nighly build yesterday and I'm still seeing unsecured faults. Is there some other jars besides the wsit ones I need to pull?

Thanks

ritzmann
Offline
Joined: 2003-06-19

I just did one more fix a couple of minutes ago. But I am only testing on the policy processing layer, there could still be things going wrong in security. I'll ask the guys to do some testing.

ritzmann
Offline
Joined: 2003-06-19

Things are working on the trunk now, should go into the 1.0 branch this week-end: https://wsit.dev.java.net/issues/show_bug.cgi?id=629

mulepic
Offline
Joined: 2007-02-05

Hi,

I noticed on bug id 621 this comment 'Works with recent wsit builds on gf b56.' The latest glassfish I could find was b55, so I installed it. I also installed the latest wsit nightly build. I'm still seeing unsecured faults. Is there another jar file I need to pull to get the complete fix? Thanks again for your help.

ritzmann
Offline
Joined: 2003-06-19

Should be OK if you installed the latest GF build from here: http://download.java.net/javaee5/trunk/installer-nightly/

Together with the latest WSIT build from here:
https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

Would you be able to provide a small WAR that we can deploy to reproduce the issue?

mulepic
Offline
Joined: 2007-02-05

Hi,

I downloaded GF and WSIT from the links you provided and I'm still seeing unsecured faults. Attached is the war. Thank you for your help.

ashutoshshahi
Offline
Joined: 2006-01-27

I do not see any fault policy in the wsdl. You will have to create a fault policy and attach it to the wsdl:fault element (inside a wsdl:operation)

mulepic
Offline
Joined: 2007-02-05

Hi,

Can you give me a little more context? I'm using NB to create the service; usually associating policy w/ messages is done for you. I'm hand editing the wsdl/wsit.xml as you suggest but I'm only getting parsing errors when I try to deploy it.

Thanks

ohloh
Offline
Joined: 2007-07-17

Associating the fault policy can also be done through Netbeans if the web method that you invoke throws an Exception. If the web method throws an Exception, along with Input and Output Policy, you can also set Fault Policy. I am attaching a netbeans project that you can refer to.

mulepic
Offline
Joined: 2007-02-05

Thanks for the help. Apparently my version of NB doesn't provide the UI to apply a policy to the fault msg. I had to add this manually to the wsit.xml

mulepic
Offline
Joined: 2007-02-05

Progress has been made; the faults are now secure. But now the next step is an issue. It looks like when faults are secured they are no longer typed. For example when the fault is unsecure the client can catch the fault like this:

try
{
//call service
}
catch (FaultException fex)

But when the fault is secured the above catch statement is passed in favor of:

catch (FaultException fex)

Here are the bodies of the fault responses:

//secured

Secure

ns2:Server
exceptionMessage


exceptionDetails

exceptionMessage

//unsecured

xmlns:ns3="http://www.w3.org/2003/05/soap-envelope">

ns2:Server
exceptionMessage


exceptionDetails

exceptionMessage

I have verified that the proxy serialization code is being called for the fault type in the unsecured case but it is not being called in the secured case.

Any help would be great!

amason
Offline
Joined: 2007-02-26

OK:

Here's my current issues with this dummy WSDL-first approach with faults:

1) When I turn off message security, it appears that the XML being sent is incorrect if I reference a type in my fault that is not of the same namespace. It appears there's a missing namespace prefix for the referenced type.

2) When I turn on message security, the SOAP faults remain unsecure.

I have attached the entire WAR built WSDl-first (minus the WSIT jars since they are too big for your upload).

Here's an example of the XML that loosk incorrect based on the WSDL/XSD.

http://www.w3.o
rg/2005/08/addressing/anonymous
http://webworks.manu.com/publicapi/DummyServices/DummyServicesPortType/
echo/Fault/DummyServicesFault
uuid:d2977742-c924-4c3c-ad8f-c0762579e082urn:uuid:cc7556bc-b468-4216-8294-c412
f892009c
S:ServerThis is a dummy faultThis is a dummy fault
DummyServicesWSDS00001
--------------------

Message was edited by: amason

Message was edited by: amason

ritzmann
Offline
Joined: 2003-06-19

> I have attached the entire WAR built WSDl-first
> (minus the WSIT jars since they are too big for your
> upload).

You should not put them into the WAR in any case.

I was not able to run a client against your service. Some observations:

- All PolicyReference elements in the WSDL in your WAR are commented out. You need to uncomment them.
- The same goes for the security policy portion of the policy attached to the binding.
- When I send a message to the service, I get the following error back. I suggest you use a simpler security policy that does not involve an STS for the current testing:

javax.xml.ws.WebServiceException: WST0029:STS location could not be obtained from either IssuedToken or from client configuration for accessing the service http://localhost:8080/dummyservices/DummyServices.
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.process(TrustPluginImpl.java:273)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.invokeTrustPlugin(SecurityClientPipe.java:378)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:159)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:135)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy75.echo(Unknown Source)
...

amason
Offline
Joined: 2007-02-26

Thanks for the reply.

I would not have expected you to be able to run the WAR. It's really there so that you can see what's in it. I was asked for the WSDL for this problem. A while back I believe you were involved in fixing a problem with faults and message security. The question is whether there's any chance that there's a problem with IssuedToken or perhaps wsdl-first that wasn't covered by that fix. We are doing message-security (IssuedToken) as well as WSDL-first development. As far as your comment on the security policy, I am fully security policy needs to be not commented out. The current policy is such so that I can show the incorrect fault XML.that is thrown when a fault is defined with a type from another namespace. The second and ongoing problem is that the fault regardless of the type is unsecure and I assume is down to either IssuedToken or WSDL-first.

Regards, Alex

amason
Offline
Joined: 2007-02-26

Here's a simple UserNameToken example built WSDL-first that should be deployable on GlassFish if you change the keystores.

Please check this out and let me know what is wrong with it as I am stumped. Regular input/output messages are fine but faults remain unencrypted.

Running 8/23 nightly build of WSIT.

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

thanks for the testcase.

But what input can i give to the echo method call so that i can test the fault scenario. So far i tried calling it this way :

try {
test.DummyServicesPortType port = service.getDummyServicesPort();
java.lang.String input = "";
java.lang.String result = port.echo(input);
out.println("Result = "+result);
} catch (Exception ex) {
throw new ServletException(ex);
}

And what i see is a secure response coming back, i guess it does not throw a Fault by default.

---[HTTP response 200]---
null: HTTP/1.1 200 OK
Date: Wed, 29 Aug 2007 10:30:37 GMT
X-powered-by: Servlet/2.5
Content-type: text/xml;charset="utf-8"
Transfer-encoding: chunked
Server: Sun Java System Application Server 9.1
http://www.w3.org/2005/08/addressing/anonymoushttp://webworks.manu.com/publicapi/DummyServices/DummyServicesPortType/echoResponseuuid:d5b4f679-1912-4eba-a6c6-9a5d066c3623uuid:59859297-7828-4103-9964-90f6ff20c8042007-08-29T10:30:37Z2007-08-29T10:35:37Zy+esOn5LeJ2/mXHWe5oXQBNqyZg=016xJTQfM6tf51p83c7GPsuluemy+esOn5LeJ2/mXHWe5oXQBNqyZg=016/o+DiJv6487FvEKyhiZmPPS/4aN16SZsR3ja2GlcyJeVmWB89v2eFmr96+W7weO/23vO3Uc/mnmMD3I+ikrxgjfcNroFKpMQA+7n1XJAZNT0Z6lMcBhU/+D0SrNnuAAMKEPzhhfXGpooOokQ9GZBxDCKETvWdiOpIQdfFSscc+etmoUc6VmJJt9HdbBhs+u1O/jWkrWddX9FGDkb2V2uiiNFHmkGPxG5ixjcX7IhJEQiGR58rap/cfAMunIaaSPYwE66Si9MEg8nzrO8QVLg4pBAKgOFqBT6gqbQOtyHTNAIde/pk2ERG0NuFtybPu01yBB/RAtYDa09+Aub/zr2st1q+1b4DUw67pbDZMBnMSR+OhqdD0otYtWmbrtY4IjYUZNcdXGQR7GqYFCsP2cjJkW1m2kJZfkQq67UquHbh94zYhOOQIqYSej7KvxG0JG8BPHLk8cn5HBaJR9L6RhjJgOfVRa0FosBFezgX4DwO231ZToHZdjE+zdK7e1aP0wy7x38eY+BDkG5U/VrZLJjxl8sqV7GObXd2EerhO8FET5ZaoDqAGEKGi7wcxcpClL+SFjTDVWNU2MlIMqQi+sSJ+S513bEWX+fwVUISqf5fAzVO1n2QZIij62cNGxDVffANLKiFxSDYYx62KIiwWAAvH6iSOr2RMlnRShECw4yYrrKCFXagAeaMfy41Vq53T2TEn2A4k7rgoUu4hJZfZHT1YVy9TrFQdDVyxreHHoAu3D3ONxxu9+MRgVQliIOMarIgylcs1mRiyD/fTTiFzpuLypjOLxjrjPjFbyPk1J1GHDA7U4oUyHpA8QP3hT8RgrJ2SO62Kxk6/JB/B9pVMXMveO7DAkEd/aBVCm3HuUH4M0Abs74tj3ENAnrqBvRaFmFNA5zDRA5a+bxnxkjh5C2xgxmYi2fwRPyJWiEvRiDP3GV+sjSxuzNv0aAcrMwaC8iC+4bkczlIlwdWegFUvEo1OEn60dcmEGed+1z8Xn8lGhCmOGUE0rEJo9dX/8gsU7I7XHs4NCMIodAv2KcpYeRTAqj7PRUaqURi9e2AnUStVMykyCeO7ONK8CjVH/FH1gJB+vr4Awal8DM4TSeH2KOVbtnXWyWwCehu7KbHweRhv4ql7uh0vxfljXO74FreK/wXUbGmI7mEAhUmSeMlpfX25lnbcwyJ//0WKWzWRD/AFPLpZFQK/YaUqUMaGkI7YVhMT42LtqYAqLbxR9hop0BywI7Le3/OkjXt5k1T8PX6YoRiJXenhsODJasKCLT/FKEJXVFiDCZp4Rub8OfxLEgn+ynS/5XZbu6hjLFyyzKmO8FGDwdEl4eZ8HKqNnV6qmPFlyWrPByPAFdt39DPpRoWRmi8FVWJOs0gnfkk/GhfoU0arSn1eaTiAMknkzo6isVQ4SXEbXsLI1qsMPWx6BfAuSu7FQyuUqgfdC3sUTMUpDRZqO5uBTnC7ee9jQ+EXQ0U3Fv36a58iePvRV8Jp/hXE0ZCmLX1xPFwZ2W8spTqycEXFIqXFkreZH97uo11+Xg2Dt4T792BhjOOKfeWbW2mhl9erLHOwcrITrICIv/Ytg3XwtkBx1JIIUfZqTBUWFEQpUIqojv2Z/Co/vRDZA5xKIvFos0X92k24P2SFonCYBHY8ONkxsrR/P0pV4XH2d3aJILmFD7oO/5NCFyoauB7ymlKpxlrn4n4Fatt03A9Qyv6mrivgZaz+J1gaMEwUK/P22NuTD8nwwfsrJdgzYEc/9+PZYwJb4BklHdvL3THidSSONZR2IVNu+qmqSSUlvY2jLqWLbMwHzc9aohlFje6+SrACIOGE7vcTPRJ0EfqNfFS79k2YH+XHo9sl32/KviR4UBmTK6xeIyVJK5CVdJ9aGvhAqecBFvCVUCbBQLVu/ySbuxv3taANgjaTkplnvW7P93D0PlKvLyIFceeNuNsQDHLCPLT/5A5UbpfU6o30P8+pZnQRDaDn84F+4EcFfnZNjdfnnXVMbPFuWWkdlWVUVBTC+DfPdSM9H1lSU4X517HPChbGETZIp+MvMNXCFbskiJMG0uqGwfk+moZ5cSeclpF/m5R1FvS5OVSkKE2hb97URNkaUa7LunpAILhWpkS4Xt0Vm7yEI/xXHs53Co6RwPReDRvicO1beRPAtMYcczV5Ui1nrxYNLDm3GTbdLIhpBocmfw3A6duyeX8tLW8JqJi+SRoH2HHETqRcGeh3jOl0ClXivWKOTEXa0s+99QBhRBygClCVMinZNjXRwY8QijPKLUzpiqodg3qbiNYtvOiNpdrupAb9R4ccGNqOcdmf24srYrVYWV6OpFrhXx7dOjx9LI7sV1e8Wl7l30AZtDT849j1tZ1/ix4G4aXp3A9+X20YZIor+WIIuAHn1O49N3zzE7M9lBOvUzWbaNohc5DlQ5OhClzGN8iycSHWz72wHzBZAJCOrGEcZ4AGlc+F9WsJpFs+GGcMCBudOBvd82ml7t7tfQX63fa6qIFJ+4PjB4+pxdEYZzwAF04c+7pLrvh1n0PqZo4uco4tN/h+uhuDNIa63HjFKnva1/h5zdObST7fxQ8yVm86Ry+b6Pkc61l4FtCCVGCBW2dfNy1jxOCS2viN2PHSI614OFYLYiEX4wMwQ3xA04lPBypbAAZmWHPlanhiqpqHJYk0yG6BC8oqrg2115Kgt6v8cxdmtBRslJ6glU6ryS80WLdGv/wh9o50hA3htWAEQBLId2F1eMqllJ0zujaaxJ56kUIH3IlHaVkNPd7xv9z1isSkmjqmz0B7dM4JJSvqy0ZXprv6bAu4vR5H0jeITUk+BFV1A4L0ahIOyqWcTQ8fju1zI7j2QdeJuVqZhwyUl9ERJHk8lZj9yMH08N0UAosEuwiiz3hgRuMuxS69yinJ0+I7GYzkdGKmn9RICKaQ7wA1exJKNqI+eAjy4BCd2azFDiF/uK34s7oYza6/oXglfY9tJuAQsZrVk142ukZsO/nNxVwb/PY1rSWHq24sqAn8PJWWxzdUNvv33iNfrst5CYbEltXhsBs+X6AZLBhd3WYDdS69AiGjDRV3VC7/Nn6nqQ65aQmT4ElcpRB+TRBUd92mYM236hywhnfa8iE+2n3MtaPUgQhdfyeP3ePFXG1uGPAIhD17pzu52vJSGdjcykIPrYy6qI6D87zpI7uiebPXcMbehF4Otj5kUub8B2Ad8URg1B03vOPkOYExGUl7qVTxEOv/QKxrPgpEyCMaDYAQ0MiU0fvxqUvgAZYeaI+FiHlBzBwJik2a2IwyyuMUpIrfiHStABrXjSOJqaF0vFvl9GkgHUr07ER17rUWVCBuM5+oOy2zQowvwIDrAZ61Sf6ltz8Aa5NWQzaTraP7SODSWB5igA5zwVmCOCKktuV/iWV92SbqF9F0/iinhzW5DJ7CoOnixGj5ID/YEwnZEKfvOrbxv5eiDsI34VC19pEtS314mvEMLVzcAdgud2xmRCm3BhFOeTIZFmiZ4YMdMpdjDN8NafMoZSNERZZsiYgisnzEB4rLO1BJaAkxYtulAFN0W7tEFrNZY0BmhrwWGdb9qCcMJgpkqtM90fa7vvPbdMukRx9dWUfauOhOqj9UNHlEl5OpaZSblItWN6VVYYpLxFV8LpxPsBWpKdKcHilVaDP7UaGEQMbVBunANtMAkC2Rbv2DkGH4FGW+kyiIW37oTCBIhsaZvv+C3jfpSe90uMtRjFfD0RTeuzlLLBnHO7A/MCqlz3mukaoNh+JwqGSkuTmmIKZ4qCIJG8nvvu8LBQ08iF7a1iIvG/zwMhHz7giNh0YETiqnVNjS7dwv0W52zmiKuS8QmVjere0e3/pLp+WAN59Spz6SuQ4T2W51aiHSIwhX/OZ5myx8ykRrP/vFJeqU148CW5jB6iyH7EvM4V7un+7Ky7hJAwEanJz6KNzRgtrVcfk+MfZXKIhLcqCVT1ScAhN8N6pPV+jY+hHE01FfGESpAJ7aDhwK7zZGCfbp9hZ0SbzC8V9IWAD/0q1mGqLZF1b4/ChOUMrgTOs4OR6hYTlOmiVcPiyhlPF6rY+UFtALU1xfEl5LpL6PPaoyOWyVFQn89jpvwWwEGPip3zd+4qAIMg7/2WRIzmsXwAe3NFQweykm4KUYqa5Ci2wqCHxuga4lD49iws+DzqjzCK7H9njBbA4+yLD/GSR7ONbfYa7duUz2PWi0c6y+6RCvYqgMloP1Udex8PJSTiFP3BCmQdd8sx49s2Xc3yKK3Xs70i0ZM8nbhTFMvX67aSPQmGjgfLo6w5YnM6lJfEuXe1+U0DmH/HYak/HkhghaDn64DVUwkaRBO9MetX0gCMixbvZzmT6QKurGopRhhfXEA0alRjaxM7redNG+pQcAUo6hpziz/S4Rm336SJHRMC5SJA15d9bLYLTf9FgPkmFaoOtCD3h+1NjuT1jvVhesw953zpEj5OwJEmCUMFRe7GHY2qar8fcxLW7B0Wd6f8FdEGDwi30nzwW1BAddmUy5BcyUN3xpI3oHB4Ly+308p9G/BIU4UeR3PknUIQdHrlhqsY/UWavVoAV4LR/tfa3wD8pbvTDJ1Q+bvipcRrghOuDgrVV678/rr4GEJU8qI975NrqJRca9o=R66hXIU1Ly7BGAhu9sFWYllBNUYMXAwAe8UVJZi0+c1VwpRP8zoX6y5UZrsTtGQYzH4rsVrXpCbgDMJscWy1YjJGFG+f9fvYyraC60w3gPEmI/bnNLxKzAYHQu8ZhbHpkGvZUDgOW5gRlwHFYftoqu7w6vOTbXyR0PFGlWWJuZXViSWs5n4Ytmlf30+7GmrY
--------------------

amason
Offline
Joined: 2007-02-26

Sorry:

Should have mentioned, pass "throw" as an argument to get the impl to generate a fault.

Thanks for looking at it.

Alex

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

I just tweaked your fault definition part in the WSDL a bit and now your faults are secured(encrypted).

Attached is the modified WSDL.

The diff of the original WSDL and modified one is as follows :

30c30
<
---
>
38c38
<
---
>

I will check with our policy/WSDL experts and get back on why the original deifinition results in Null Fault Policy being returned for the original WSDL.

Thanks.

ritzmann
Offline
Joined: 2003-06-19

I opened a bug for this issue:
https://wsit.dev.java.net/issues/show_bug.cgi?id=671

I hope to have it fixed within a couple of days (on the trunk, the WSIT 1.0 release branch is frozen). But I believe the work-around that Kumar gave you should keep you going.

amason
Offline
Joined: 2007-02-26

Thanks for the pointer. I have updated my end and also now see an encrypted fault. However, I still see an interop problem with WCF.

When I have message security enabled I am unable to catch a typed fault in C# FaultException but just get FaultException. With or without message security I get a FaultContractAttribute action of "echo" rather than the fully qualified one that WSIT sends. If I edit the gen'd code and change the action to match what WSIT sends then I can catch the typed fault. However, this is not the case at all with message security. With the now encrypted fault, I cannot seem to get the typed fault.

If it is possible, I am wondering if you could test this service with WCF and see if the result is the same. Our main goal is to have secure, typed faults across an interop boundary using WSDL-first design.

I also do not want to have to edit the generated code of svcutil.

Please let me know of any findings.

kumarjayanti
Offline
Joined: 2003-12-10

Sounds like a repeat of what mulepic had posted sometime ago.

Jitu had provided a clarification and then it seems things worked for him. Please see if you have the same problem.

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

Thanks

amason
Offline
Joined: 2007-02-26

1) I believe that mulepic is saying that he had to edit the C# generated code for that is where you find a FaultContractAttribute. I don't agree this to be acceptable. The interop should work without editing generated code. If there's somethign that can be done in the WSDL to affect the generated code, then great. I just don't know what it is.

2) I have already done this edit of the action in my FaultContractAttribute just to see if it would work and it does not.

If at all possible, I would appreciate someone looking at a WCF client proxy and see the problem here.

kumarjayanti
Offline
Joined: 2003-12-10

Hi Amason,

Would you please file an Issue with WSIT describing the problem and also attach your WSDL and schema definitions to it.

If you think there is an INTEROP issue with Typed Faults even without Message-Security enabled then file one bug for that.

And if you think there is a separate Problem when Message-Security is enabled then please file another issue for that against WSIT Security.

We are keen to make sure we fix any issue we have here.

Thanks.

amason
Offline
Joined: 2007-02-26

OK:

I am back on this again with WLS 10 and the same or similar WSDl and the exact same error with a nightly build of 8/13. It seems to make no difference whether I specify encrypted/signed body. The abbreviated stack trace indicates a problem in SignatureProcessor and XML parsing around IssuedToken. This problem occurs only when I throw a custom SOAP fault. The normal invocation of methods in the service works perfectly. Please advise.

Caused by: java.lang.NullPointerException
at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.importNode(Co
reDocumentImpl.java:1478)
at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.importNode(Co
reDocumentImpl.java:1444)
at com.sun.xml.messaging.saaj.soap.SOAPDocumentImpl.importNode(SOAPDocum
entImpl.java:147)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.importNode(SOAPPartImpl.
java:444)
at com.sun.xml.wss.impl.dsig.SignatureProcessor.prepareForSymmetricKeySi
gnature(SignatureProcessor.java:1760)
... 45 more

kumarjayanti
Offline
Joined: 2003-12-10

We will take a look at the attached wsdl's and get back.

Thanks.

ericnishant
Offline
Joined: 2007-04-19

Referring to the policy for the soap fault that is present in the wsdl which you attached :













It appears that *only* the Addressing headers are intended to be secured (signed), and not the Body. Can you modify the above policy to something like:




/

The above policy will sign the soap:Body and thats where the soap:fault will lie.

mulepic
Offline
Joined: 2007-02-05

The policy I used to prove this was:


-
-


-










If the policy wasn't correct then the non-faulted call would have failed as well. Also, I got confirmation that sending unsecured faults is a current bug that is being looked at.

kumarjayanti
Offline
Joined: 2003-12-10

Here is the bug :

https://wsit.dev.java.net/issues/show_bug.cgi?id=619

And it appears it is fixed, can you try the latest nightly and let us know.

https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=5472&e...

Thanks

amason
Offline
Joined: 2007-02-26

Hi:

I must be doing something wrong cos' I can't get even non-fault messages to work with this latest nightly build. Attached is the WSDL, client WSDL and XSDs. Is there something wrong with these? I get a NullPointerException on the java client.

Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parseModel
INFO: WSP1049: Loaded WSIT configuration from file: file:/D:/release/v80/Webworks/weblogic/config/properties/wsit-client.xml
Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2005/08/addressing}UsingAddressing" was evaluated as "UNKNOWN".
Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".
Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://schemas.sun.com/2006/03/wss/server}KeyStore" was evaluated as "UNSUPPORTED".
Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://schemas.sun.com/2006/03/wss/server}TrustStore" was evaluated as "UNSUPPORTED".
Jun 29, 2007 3:33:49 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".
Jun 29, 2007 3:33:51 PM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parseModel
INFO: WSP1049: Loaded WSIT configuration from file: file:/D:/release/v80/Webworks/weblogic/config/properties/wsit-client.xml
Jun 29, 2007 3:33:51 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2005/08/addressing}UsingAddressing" was evaluated as "UNKNOWN".
Jun 29, 2007 3:33:51 PM [com.sun.xml.ws.policy.EffectiveAlternativeSelector] selectBestAlternative
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "PARTIALLY_SUPPORTED".

java.lang.NullPointerException
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleEncryptedData(SecurityRecipient.java:479)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:346)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:250)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:205)
at com.sun.xml.wss.jaxws.impl.SecurityPipeBase.verifyInboundMessage(SecurityPipeBase.java:424)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:231)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:180)
at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.invokeRST(TrustPluginImpl.java:361)
at com.sun.xml.ws.security.trust.impl.TrustPluginImpl.process(TrustPluginImpl.java:232)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.invokeTrustPlugin(SecurityClientPipe.java:375)
at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:159)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:134)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:244)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:224)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:117)
at $Proxy40.getResourceAccess(Unknown Source)
at ut.com.manu.webworks.publicapi.securityservices.UTSecurityServicesTestCase.testGetResourceAccess_HasAccessToResource(UTSecurityServicesTestCase.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

mulepic
Offline
Joined: 2007-02-05

Maybe there is something basic I am missing. I have a service that is using Username Auth. w/ Sym keys. When the operation executes successfully i get a msg that is nicely encrypted and signed.

When an exception is raised in the operation I get a message like this:

xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous xmlns="http://www.w3.org/2005/08/addressing">http://pkgFault/FaultService/FaultOperation/Fault/Exception xmlns="http://www.w3.org/2005/08/addressing">uuid:0a6e0c5e-aee7-466a-ae4c-3dd1117c3443 xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:cdcc52a4-4dc3-41c0-ad90-d32644861dc8 :Fault xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns3="http://www.w3.org/2003/05/soap-envelope">ns2:ServerFaultException > xmlns:ns2="http://pkgFault/">FaultException

since this message is not signed/encrypted the wcf client raises a MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party.

Should the client expect the message to be signed/encrypted or just accept unsecured faults?

amason
Offline
Joined: 2007-02-26

Well, we are using a rather date nightly build from around March 23. So, do you know of code changes that may have affected this issue since? Is there anything inherently wrong in how am doing the SOAP fault along with message security?

Thanks for any help, Alex

kumarjayanti
Offline
Joined: 2003-12-10

Hi Amason,

Please let us know which build of WSIT you are using, because we do have testcases that secure faults and they seem to be passing.

Thanks.

mulepic
Offline
Joined: 2007-02-05

I would like to add more information to the question above. It seems when an Exception/fault is thrown from the service the resulting SOAP message is not encrypted/signed when ws-security is being used. For example we have a web service that uses ws-security. When the operation throws an exception the message returned to the wcf client is not encrypted and/or signed as a message would otherwise be when an exception is not raised.

Therefore on the client end a MessageSecurityException: unsecured fault.... is being generated with the inner exception being the original one thrown in the service. The client is expecting is to catch a FaultException but it's clear this is not happening b/c the msg from the service is not secure. We have verified this to be a ws-security particular issue b/c the same scenario works great when ws-security is not used.

So is there an issue with ws-security and exceptions being raised by the service?

venu
Offline
Joined: 2003-10-22

Mulepic,

I don't think this is the case, our testing team has been testing this feature for quite sometime. If you are seeing this please file a issue.I will look into the above usecase.