Skip to main content

Can't secure JAVA SE 6 WebService - code based on example doesn't work

70 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kumarjayanti
Offline
Joined: 2003-12-10

> Thanks, I have made some progress all I had to do
> after changing the key algorithm was to implement
> DecryptionKeyCallback.X509IssuerSerialBasedRequest in
> my security callback handler.
>
> Client and Server are now working!

OK.

>
> When the password is wrong the client gets:
> javax.xml.ws.WebServiceException:
> java.net.SocketException: Unexpected end of file from
> server
> at
> com.sun.xml.ws.transport.http.client.HttpClientTranspo
> rt.checkResponseCode(HttpClientTransport.java:238)
> at
> com.sun.xml.ws.transport.http.client.HttpTransportPipe
> .process(HttpTransportPipe.java:151)
> at
> com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(
> SecurityClientPipe.java:185)
>
>
> I sort of expected an exception that was more to the
> point.. I then determined that this is caused by
> having assertions enabled on the server.
> The server shows:
> SEVERE: WSS1408: UsernameToken Authentication Failed
> java.lang.AssertionError
> at
> com.sun.xml.ws.message.stream.StreamMessage.(Str
> eamMessage.java:166)
> at
> com.sun.xml.ws.security.opt.impl.incoming.SecurityReci
> pient.validateMessage(SecurityRecipient.java:222)
>
>
> When I disable assertions on the server the client
> using a wrong password fails with:
> javax.xml.ws.soap.SOAPFaultException: Invalid
> Username Password Pair
> at
> com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(
> SOAP11Fault.java:187)
> at
> com.sun.xml.ws.fault.SOAPFaultBuilder.createException(
> SOAPFaultBuilder.java:116)
> at
> com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(Syn
> cMethodHandler.java:119)
>
>
> Since a wrong password is a perfectly valid "failure"
> shouldn't the server react better with assertions
> enabled?

I will look into this and get back.

Thanks.

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

The fact that you had to change your CallbackHandler indicates to me that you are using XWSS 2.0 style security for the client and NOT WSIT style security.

Once you have an Endpoint with published WSDL (containing Policy), it is very easy to develop a WSIT style client for the service using NetBeans. All you have to do is create a WebServiceReference in your J2SE Client and point it to the WSDL URL of the Service. Then a wsit-client.xml config file should be automatically generated for you.

When you use WSIT style security the default CallbackHandler in WSIT takes care of handling all types of callbacks and you do not have to code and CallbackHandler.

It is important to use WSIT style security on both client and server side if you want the benefits of the Streaming Security Implementation which is used by default when you are using WSIT style security.

Thanks.

Message was edited by: kumarjayanti

swpalmer
Offline
Joined: 2003-06-10

> Hi,
>
> The fact that you had to change your
> CallbackHandler indicates to me that you are using
> XWSS 2.0 style security for the client and NOT WSIT
> style security.
>
> Once you have an Endpoint with published WSDL
> (containing Policy), it is very easy to develop a
> WSIT style client for the service using NetBeans. All
> you have to do is create a WebServiceReference in
> your J2SE Client and point it to the WSDL URL of the
> Service. Then a wsit-client.xml config file should be
> automatically generated for you.

That is EXACTLY what I did.

> When you use WSIT style security the default
> CallbackHandler in WSIT takes care of handling all
> types of callbacks and you do not have to code and
> CallbackHandler.

Then I don't understand why it didn't work.

kumarjayanti
Offline
Joined: 2003-12-10

jaxws-rt.jar is just JAXWS runtime.

webservices-rt.jar is the entire WSIT/Metro Runtime Stack which contains jaxws-rt within it and it contains among other things

1. WS-Security
2. WS-ReliableMessaging
3. WS-Trust
4. WS-SecureConversation
5. WS-Transactions
6. WS-Policy
7. Support for SOAP/TCP
8. FastInfoset support

etc.

Thanks

Message was edited by: kumarjayanti

smjain1
Offline
Joined: 2007-10-04

Hi,
I am trying to enable MTOM functionality on Netbeans 5.5.
I have WSIT enabled.
I dont see the MTOM policy updated in WSDL. Is it something to do with the jaxws jars I have. I downloaded the latest WSIT build so expected this to work.
Can you please advice
Regards
Shashank

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Thanks for the feedback. I admit the sample is not in very good shape. Please see my clarifications inline...

> The entire contents of the config file that I
> referenced are:
>
> > xmlns:xwss="http://java.sun.com/xml/ns/xwss/config"
> dumpMessages="true" >
> > passwordDigestRequired="false"/>
> /xwss:SecurityConfiguration>

If this is the content of you server side config file and if your client side config file looked something like this :



Then i see no reason why the SignatureKeyCallback should be made (unless you have hit upon a Bug). If you think this is happening then please file an Issue at https://xwss.dev.java.net

>
> Also, when I see instructions that read " > warnings and errors>" it makes me nervous. When I
> make my own changes to the sample how will I know
> what warnings or errors are relevant?
>

The reason for this kind of instructions in the README is the following:

The sample has both the client and server Java files in the same directory. There is no ant script or anything. I just quickly wrote down the sample for a user. Now when we compile the Server Classes the Client code won't compile because the Client Artifacts get generated only after the wsimport call (and the wsimport call can be made only after the server is ready).

So i was actually asking users to ignore the compile errors relating to client code while compiling the server.

> I hope you understand why
> "simplejdk6ws\ServerSecurityEnvironmentHandler.java:43
> 0: warning: sun.security.x509.KeyIdentifier is Sun
> proprietary API and may be removed in a future
> release" is a warning I don't want to ignore. In
> general a sample project that is full of warnings and
> errors is scary. I find it strange that I am being
> pointed to it to use as a basis for my work.
>

Appreciate your feedback.

> I wanted to see what happened when I sent a request
> without any username or password and the server
> didn't fail gracefully:
>
> SEVERE: javax/xml/rpc/server/ServletEndpointContext
> java.lang.NoClassDefFoundError:
> javax/xml/rpc/server/ServletEndpointContext
> at
> com.sun.xml.wss.SubjectAccessor.getRequesterSubject(Su
> bjectAccessor.j
> ava:78)
> at simplejdk6ws.Main.sayHello(Main.java:43)
> ms JAX-RPC is mixed in with the JAX-WS and the
> classpath given in the README is incomplete.

There is no mixup of JAXRPC and JAXWS. This particular sample should not use JAXRPC at all. The above error can only happen if you do not have the latest WSIT Jars. Can you please download WSIT jars from :

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

And try. You should not see this kind of an exception.

Please let me know.

Just to be sure the README is not WAY OFF the mark i repated the steps VERBATIM on a Windows Machine and attached are my client and server logs.

The Warning about sun.security.x509.KeyIdentifier is the only prominent warning and we are trying to find ways to get over this.

Thanks.

swpalmer
Offline
Joined: 2003-06-10

I updated the WSIT jars from the link you provided and now have the example working. Thanks. I guess the previous "latest" release I was using was not late enough. (I think it was a WSIT 3 early access build)

I'm going to digest the example code a bit and try these new WSIT jars on my main project when I get into the office tomorrow.

I appreciate your patience as we sorted this out. :-)

I may be back with further questions... but if not consider it a good sign ...

swpalmer
Offline
Joined: 2003-06-10

Ok.. I'm looking over the sample code and there is something that is not clear.

I see the code for setting up a callback handler is commented out in both the client and the server. E.g.:

[code]
public static void main(String[] args) throws Exception {

try { // Call Web Service Operation
client.MainService service =
new client.MainService();
client.Main port = service.getMainPort();
((BindingProvider)port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "Ron");
((BindingProvider)port).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "noR");

//List chain = new ArrayList();
//chain.add(new simplejdk6ws.SecurityHandler("client"));
//((BindingProvider)port).getBinding().setHandlerChain(chain);
String result = port.sayHello("TOM WITMER");
System.out.println("Result = "+result);
} catch (Exception ex) {
// TODO handle custom exceptions here
throw ex;
}
}
[/code]

I also see the XML configuration files in the META-INF folder. They appear to be what connects the callback handler code to the service. But I don't understand how the XML config files are linked to the web service, as the file name of the config files is not what I would have expected. I.e. the config file is not named "wsit-
.xml" but simply "server_security_config.xml" and "client_security_config.xml"

How is the relationship to the config file established?

kumarjayanti
Offline
Joined: 2003-12-10

>
> I see the code for setting up a callback handler is
> commented out in both the client and the server.

That's because the configuration files in META-INF are connecting up the CallbackHandlers.

> But I don't
> understand how the XML config files are linked to
> the web service, as the file name of the config files
> is not what I would have expected.

This is because here we use XWSS 2.0 style security and not WSIT style security. The security configuration is also using Proprietary syntax and not WS-SecurityPolicy Assertions as is the case with WSIT.

> I.e. the config
> file is not named "wsit-
> class>.xml" but simply "server_security_config.xml"
> and "client_security_config.xml"
>
> How is the relationship to the config file
> established?

So the client side security config file in XWSS 2.0 can either be named client_security_config.xml or it can be programmatically set on the Request Context. I believe i mention this in the README.

The Server Side security config can be named server_security_config.xml or it can be named as _security_config.xml .

ServiceName as in Deployment Descriptor. We only take the LocalPart here which is a limitation.

If you are looking at using WSIT Style Security, we still need to create a Secure WSIT sample that works with a JDK6 Endpoint. I may work on, maybe next week because this week i am a little busy.

What we have so far is two of our Non-Security Team members trying out WSIT with JAVA SE 6 and here is what they wrote in their blogs :

http://blogs.sun.com/ritzmann/entry/wsit_with_a_j2se_endpoint

http://blogs.sun.com/arungupta/entry/tango_on_javase_6

Thanks.

swpalmer
Offline
Joined: 2003-06-10

Sorry... I was so distracted by it actually working that I stopped reading further in the README :-)

I've noticed during my testing that jaxws-rt.jar and webservices-rt.jar have a lot of the same classes and that has been causing me grief in my testing. How are they related?

swpalmer
Offline
Joined: 2003-06-10

I read those other blogs... I've looked at them before, but I'm "getting" them more now.

These magic XML files seem to do a lot. Your example uses XWSS 2.0 security, but it appears that WSIT security can be used just by changing the configuration file to one with the wsit-packageName.serviceName.xml naming convention and tweaking the contents.

I'm still confused over what technology I actually end up using. jaxws* jars seem to be replaced with webservice* jars and I haven't seen a reference to that name change anywhere. I think that the webservice stuff is only augmenting the jaxws stuff, not replacing it entirely... but I don't seem to need jaxws-rt.jar anymore. In fact I have to make sure it isn't on the classpath or things fail.

I'm going to try to get WSIT security working, but I don't know the XML structure very well.

swpalmer
Offline
Joined: 2003-06-10

Btw, even though I have my service working with a plain text password I am still getting a SignatureKeyCallback.DefaultPrivKeyCertRequest callback on both the server and the client.

My config file is:








mypackage.SecurityEnvironmentHandler

You mentioned above that JAXWS didn't mix with JAXRPC... but I guess it does for the XML config?

kumarjayanti
Offline
Joined: 2003-12-10

> Btw, even though I have my service working with a
> plain text password I am still getting a
> SignatureKeyCallback.DefaultPrivKeyCertRequest
> callback on both the server and the client.
>

I need to check this.

> You mentioned above that JAXWS didn't mix with
> JAXRPC... but I guess it does for the XML config?

Yes that was a bad choice for the Root Element Name when we designed Security for JAXRPC. We did not anticipate that there would be JAXWS in future :-(.

Thanks.

tuhink
Offline
Joined: 2007-05-31

I am afraid, I am seeing an old problem with XWSS 2.0. All I get in the callback handler is SignatureKeyCallback and not the password and username callback that are expected.

How can I get out of this?

xhunterx
Offline
Joined: 2007-07-05

Thank you very much for your attention.

Cheers.

xhunterx
Offline
Joined: 2007-07-05

I'm afraid I am encountering precisely the same problem as swpalmer's original: when attempting 2.0-style configuration of xwss 3.0, my configuration is consumed but the only callback that is ever fed back is SignatureKeyCallback and not the (expected) PasswordValidationCallback.

Manipulating the config to have multiple or errant elements breaks the configuration in expected ways and leads me to believe that the problem is not in the makeup or IO of the config file itself, but something else entirely.

My config is as follows:



Again, the CallbackHandler seems to be called during processing of factory.createProcessorForSecurityConfiguration; it simply always provides a single SignatureKeyCallback instance, even for configs that have nothing to do with signature validation.

Thanks for any and all help in this regard.

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

Yes i have found the problem. This occurs in XWSS 3.0 (not in XWSS 2.0). I have made a fix for this. We are actually trying to do some optimization in WSIT by trying to get the self-certificate apriori, but this should not be called for XWSS 2.0 style Custom(user-supplied) CallbackHandlers.

So i have fixed the problem in my local workspace. I will commit the fix to WSIT Main Trunk latest by monday.

Thanks a lot for bringing this up again. I guess i never looked into it seriously when swpalmer reported it.

Other than this i hope your app is working correctly ....

Thanks.

Message was edited by: kumarjayanti

kumarjayanti
Offline
Joined: 2003-12-10

Hi,

The first step for you is to try and run the SAMPLE by following the README. Once you are successful in doing that then it is very easy to modify the sample to do Just username-password authentication.

Specifically the sample here : https://xwss.dev.java.net/servlets/ProjectDocumentList?folderID=7894&exp...

does username-password authentication and in addition it encrypts the username-password and also signs and Encrypts the SOAP-Body and the username-password.

Please try to run this sample as is and then we can discuss any questions you have.

Specifically, if you throw UnsupportedCallbackException then things won't work.

If you do not wish to have the SignatureKeyCallback made then you should remove any and and elements from the client and server security configuratiuon files.

Thanks.

swpalmer
Offline
Joined: 2003-06-10

I will attempt the example that you have linked, but please note that the example that I linked does not use and and in the config file.

The entire contents of the config file that I referenced are:



Also, when I see instructions that read "" it makes me nervous. When I make my own changes to the sample how will I know what warnings or errors are relevant?

I hope you understand why "simplejdk6ws\ServerSecurityEnvironmentHandler.java:430: warning: sun.security.x509.KeyIdentifier is Sun proprietary API and may be removed in a future release" is a warning I don't want to ignore. In general a sample project that is full of warnings and errors is scary. I find it strange that I am being pointed to it to use as a basis for my work.

I wanted to see what happened when I sent a request without any username or password and the server didn't fail gracefully:

SEVERE: javax/xml/rpc/server/ServletEndpointContext
java.lang.NoClassDefFoundError: javax/xml/rpc/server/ServletEndpointContext
at com.sun.xml.wss.SubjectAccessor.getRequesterSubject(SubjectAccessor.j
ava:78)
at simplejdk6ws.Main.sayHello(Main.java:43)

It seems JAX-RPC is mixed in with the JAX-WS and the classpath given in the README is incomplete.

So I complied the client, but the README step for compiling the client (using a wildcard) didn't actually compile the client code. I had to type out the full name of simplejdk6ws\SimpleWSClient.java

Then running the client failed with the same exception:

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: javax/xml/rpc/server/ServletEndpointContext
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:187)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:116)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:254)
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 $Proxy25.sayHello(Unknown Source)
at simplejdk6ws.SimpleWSClient.main(SimpleWSClient.java:40)
Caused by: java.lang.NoClassDefFoundError: javax/xml/rpc/server/ServletEndpointContext
at com.sun.xml.wss.SubjectAccessor.getRequesterSubject(SubjectAccessor.java:78)
at simplejdk6ws.Main.sayHello(Main.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
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.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:106)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:91)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:65)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:68)
at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:552)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:524)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

So I followed the instructions in the README to the letter and it doesn't work.

swpalmer
Offline
Joined: 2003-06-10

I flushed out my SecurityHandler based on the code I found here:

http://blogs.sun.com/geertjan/resource/HiServerSecurityHandler.java

I believe I am know responding properly to the SignatureKeyCallback.DefaultPrivKeyCertRequest which is also the only callback I ever get.

My web service starts up now, but WITHOUT any security.

I have not bothered to investigate why the sample project mentioned above does not work. (Quite frankly the sample is in a very poor state, and if you are offering it as an example you really should clean it up.)

This is quite frustrating as I'm sure you can imagine.