Authentication for webservices

[david.salter]

I have some SLSB's which I've secured using JAAS. As a consequence of this, my webservices (WS4EE) are also secured and are no longer accessible from a "standard webservice client".

Is it possible for my users to now access these Webservices using a non-JAAS enabled client (e.g. C#).

Is this type of authentication a standard across webservices, or should I be using something other than JAAS. My primary reason for using Webservices is to provide interoperability between different clients.

Thanks,

Dave.

[thomas.diesler]

There is no standard portable way to authenticate against a service endpoint. If fact the spec discourages the use of the javax.xml.rpc.security.auth.username property on the Call object.

However, securing a SLSB with the standard J2EE role mechanism should be sufficient to secure the endpoint. Question is, how does client propagate the pricipal/credential information.

If you are using HTTP transport you could setup basic, form based or client certificate authentication depending of whether your ws clients support it.

I'll put an example on the WIKI, stay tuned.

[david.salter]

I've set my webservice up to use basic authentication in thejboss.xml file as shown below

<port-component>
 <port-component-name>AdministrationCoordinator</port-component-name>
 <port-uri>Admin</port-uri>
 <auth-method>BASIC</auth-method>
 </port-component>

However when I try to access this using a .NET client, I get a HTTP 505 - Version not supported error. Why is this - what am I doing wrong?

The C# code I am using is as follows:

 ad.AdministrationCoordinatorEJB admin = new ad.AdministrationCoordinatorEJB();
 NetworkCredential creds = new NetworkCredential("user", "user");
 CredentialCache cache = new CredentialCache();
 cache.Add(new Uri("http://localhost:8080"), "Basic", creds);
 admin.Credentials = cache;

 try
 {
 String name = admin.doStuff();
 MessageBox.Show(name);
 }
 catch (Exception ex)
 {
 MessageBox.Show(ex.Message);
 }

[thomas.diesler]

Have you tried to access a normal tomcat webapp that uses BASIC authentication from C#? Maybe this is not WS specific.

[cglommen]

was this ever resolved? I have the same exact problem.

[cglommen]

I found that a workaround for this is to set the .NET client to http 1.0. This is very unfortunate. Please resolve this issue.

I am now getting an "Insufficient method permissions" exception, but this is a different issue that I'm looking into.

[thomas.diesler]

From what you are saying I take that this is a HTTP1.1 / Tomcat 5.x issue. Web Services are irrelevant. Is this true?

Please report through the SF issue tracking and provide a simple sample deployment that allows us to reproduce the issue.

Thanks

[david.salter]

"cglommen" wrote:
I found that a workaround for this is to set the .NET client to http 1.0. This is very unfortunate. Please resolve this issue.

I am now getting an "Insufficient method permissions" exception, but this is a different issue that I'm looking into.

Can you explain how you set the .Net client to HTTP/1.0 so I can try it out on my app and see if it works?

Thanks,

Dave.

[david.salter]

I've just tried this again with 4.0.1 and it does look like a HTTP 1.1 problem with Tomcat.

If anyone is interested, the workaround is to tell your .NET webservice to use HTTP 1.0 by adding the following code to your proxy class.

protected override System.Net.WebRequest GetWebRequest(Uri uri)
{
 System.Net.HttpWebRequest req;
 req = (System.Net.HttpWebRequest)base.GetWebRequest(uri);

 req.ProtocolVersion = System.Net.HttpVersion.Version10;
 return req;
}

I'll try and post a sample app as a bug report onto SF.

btw, when you do this, it all works like a charm! Are there any downsides to using HTTP 1.0 instead of 1.1?

Cheers,

Dave.

[manderson]

The big drawback we are currently facing is the pre-notification that has to be done for all our .Net customers. Additionally from within the Visual Studio framework, any updating of the web reference will cause this patch to go away and it has to be re-added.

[cglommen]

Is anyone else using C# clients? This seems like a serious enough interoperability issue that the JBoss team would want to address it. It's quite simple to reproduce:

1. set up JBoss using Basic HTTP authentication.
2. create a .NET client (C# perhaps)
3. make request.
4. see 505 error.
5. change .NET client to be HTTP 1.0 only
6. make request
7. request succeeds.

I'll cross post this in the security forum as well, to give it some exposure.

[markeaston]

Yes we are implementing a C# app talking to J2EE web services. So it is important to us. Cheers

[thomas.diesler]

I created an issue in JBossWeb for it

http://jira.jboss.com/jira/browse/JBWEB-11

[ebu]

Hi all.
I've solved the same problem by adding to the generated wsdl the auth headers (i failed to make java2wsdl tool to generate headers, so i've written a "header adder"...) to be filled by C# client with login/password info and then parsed with custom axis handler.

Further the credentials are processed by JAAS and JACC interceptors in the standard way... not very elegant, but it works...

wbr, eugen.

[kkurni]

You can use Partial Class

That's the solution to keep your code. so when you updating the proxy class, you still can maintain your own code...