I am using Apache SOAP 2.2 with Orion 1.5.2. I have some beans which need to know which user had called the method of the beans. While invoking them using RMI, I pass the user id and password to the context based on which I am authenticated. The beans can thus get the user id using getPrincipal and getSecurity in the method.
The same is needed when I invoke the method using SOAP. Apache SOAP does not accept any user id and password (atleast I have not provided it) at the client end. I am really not able to figure out what is the user id used and how do I make the SOAP service accept the user name and password from the client.
Any thoughts ???
I am also facing a similar situation. My ejb's have two kinds of clients, one through JSP/Servlet and other through SOAP.
I am trying to figure out how to do authentication and login through SOAP. Unfortunately, there is no way to access the http session object inside the SOAP server object. Otherwise, I could provide a login() method in the SOAP object and store the user credential in the session object after the authentication.
It seems like, I have to roll out my own session manager and pass session ID as arguments in the SOAP method calls.
Any ideas from any one out there?
How about, making a servlet which takes care of login (as usuall J2EE security model) and then passes the request to the standard SOAP servlet and returning the result from the SOAP servlet. What I mean is a layer between the SOAP servlet and the user...
I was faced with the same problem, and I thought I'd consult with someone before I implement it myself ;-)
To me I just don't see how you could make such a complicated protocol as SOAP and not incude anything on authentication. I'll avoid any snide jokes about the fact that MS drove this protocol and avoided this key feature :).
If you're only going to use HTTP as transport, then leaving it up to the Web server/servlet engine to do authentication is ok. But SOAP doesn't have to use HTTP.
I would strongly recommend including some type of security in the SOAP messages themselves, whether that's digital signatures or some type of password scheme is up to you.
This feature is probably under development. Take a look at the "Simple Object Access Protocol (SOAP) 1.1 W3C Note 08 May 2000" at W3.ORG at http://www.w3.org/TR/SOAP/#_Toc478383535
8. Security Considerations
Not described in this document are methods for integrity and privacy protection. Such issues will be addressed more fully in a future version(s) of this document.
Hopefully the situation will change in the nearest future...
Regarding the point made about a work-around. The problem in my case is that I have to authenticate with the container's security manager. Given this, I need to be able to pass the user name and password while getting the context object. Here comes the problem - rpcrouter servlet creates the context object. The unfortunate part it that it does not accept any parameter for user id and password. Hence even though I have a servlet "in front" of rpcrouter, it would not be of much help.
Two options that I have are
1) change the code of rpcrouter
2) extend rpcrouter and override "some" methods (I am not sure how this would behave. Morever I dont know the list of methods that I will have to override) so that the context takes user name and password from the client. I would then use then deploy all my services with this servlet.
One last interesting thing is that rpcrouter talks only post so passing the user name and password would also necessiate a socket connection.
Have I got it right ?
Any comments ???
Thanx a lot
The proxy servlet could do authentication. For any request, the proxy servlet could get the user context from the http session and then modify the SOAP request to include the user context data as the first argument and then call the SOAP servlet.
I just had the thought that you could wrap authentication into your web service manually. the easiest way to do this is to pass Username and Password information with each method call. You can then use some sort of proxy that wraps your actual worker implementation and checks for authentication information first. This sounds weird but is really the only way to maintain information in a stateless system.
In the COM+ world this is generally how we handle things because the party line from MS is that Stateful Sessions and Entities don't scale. In fact, with COM+ you don't have either. So we will manually create a unique Session ID and enter it into the database, then we pass this information with each subsequent request. This can be replicated in SOAP as well.
Alternatively, you could initally have a seperate service that handles the authentication using Stateful Session Beans. So you log on first, obtaining some sort of ID or even the Session Handle itself! Serialising the Session Handle would be clumsy but it could work and objects can be transmitted via SOAP if you have Java at either end. Then you can use the proxy to authenticate before handling the sertvice itself.