I've got a j2ee web application using j2ee security, so the identity of the user is propagated from WebSEAL to the application, running in WAS7. I'm now trying to make a SOAP webservices call and propogate the user identity in that webservices call. To do this, I grab the LTPA (WSCredential) and LPTA2 (SingleSignOnToken) using the WSSubject calls and attach them to the webservices call using.
bp.getRequestContext().put(Constants.REQUEST_TRANSPORT_PROPERTIES,sendTransportHeaders);
where bp is my BindingProvider. This all should work. But when I make a webservices call, I get back this exception.
Cause =java.io.IOException: Unable to deserialize the Subjects in this Context
I looked at the fields within the LTPA token and all seems right (same realm between the token and the j2ee security realm webservice I'm calling, the token is forwardable, etc), and I cannot find much about this error online, except for (what seems to be an unrelated) case when trying to pass it into the EJB and one case where the realms don't match.
Any ideas? Thanks.
Can you state clearly as to what you are trying to do here?
You should be able to pass the LTPA tokens across transparently with just configuration instead of trying to write some code to achieve the same.
The Web Applications making the Web Service calls to another WebSphere server.
have a quick read at this.
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/0607_desprets.html
Things in WAS7 should be very similar to WAS V6.
HTH
Manglu
#jeffsix: are you trying to make a webservice call from application running in one websphere server to another application in another websphere server? Make sure LTPA keys are same on both server.
Related
I am facing issue with shiro.
We have two applications(two WARS) on the same weblogic server 12c.
One WAR is UI which was integrated with CAS.
Second WAR is Jersey Rest services.
My problem is UI was auntheticated succefully and JsessionID was passed back to Rest Services while communicating with them.
Before reaching to the service we wrote one shiro filter class each time Subject is valid or not.
And also in our UI there is a requirement to call the Rest Service (One specific service) in every one minute.
Issue: Each time call reaches to shiro filter class, we are getting the different subject. i tried to print the sessionId from subject (each time its different), even though user was authenticated successfully in UI and in the backend some time user name is shown as null. Can you pls help.
Subject subject = getSubject(request, response);
There are a few things that typically cause this.
If you are handing the login yourself (by calling something like subject.login() directly, instead of letting the ShiroFilter handle it)
Both application servers are managing the sessions outside of Shiro: See https://shiro.apache.org/session-management.html#session-storage
That said, I'd need more details of how your app is setup. What do your cookies look like, how are your app servers configured, etc.
I have a client - server application which uses cxf DOSGi [1]. Now I want to authenticate the clients from the server and create a session for the client. The client will have a cookie which is used to access the service once authenticated. I would like to know what is the best way for the server to access the HTTP session and the best way to store a cookie at the client end once authenticated.
I was thinking of making a custom Session object at application level once authenticated and send a Cookie object to the client. So when the client accesses the service methods, it will pass the cookie as an argument. The client will be validated in every service method. But I dont think this is the best way to handle this since every service method must have a separate argument to pass the Cookie.
I came across this when I was googling [2]. Is it possible to get "WebServiceContext" in the service in DOSGi? Even if I get it, how would I store the cookie at client end and make sure the client sends the cookie in every subsequent web service call?
[1] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html
[2] How can I manage users' sessions when I use web services?
Any help is highly appreciated.
Thanks.
You can use a custom intent to control authentication. Basically an intent is a CXF feature that is applied to the webservice by DOSGi. You create the feature in a separate bundle and then publish it with a special property for its name: See the DOSGi reference guide.
In a project we created a feature that read a threadlocal containing the authentication context and used the credentials stored there to populate the CXF authentication. So you just have to store the credentials once into the threadlocal at the start of you application and all calls work.
Currently there is no simple documenation or example for this case but I plan to create it in the near future as authentication is a common problem. I plan to use shiro as an authentication framework and write a generic adapter for CXF. I will add a comment or another answer as soon as I got it ready. In the meantime you can try to do the same yourself.
I have a couple of http methods in my application which is hosted in JBoss.
And Now I am trying to find some kind of hot-way to disable one of them,like click a button in a certain of page or calling a certain of http method. What i means of 'disable it' is making any web client which intends to send get/post request to it will go to failure . Maybe we can say the web client will got a http 404 response.
Can anybody give me some solutions? Thanks.
I think JMX would be appropriate for this situation.
You can pretty easily create an MBean (Managed Bean, a component of JMX) with Managed Attributes corresponding to boolean's for each of the endpoints you want to be disable-able. Registering it is the hard part, but there are libraries out there that make working with JMX easier. Spring has good support for setting up and working with MBeans.
As far as a JMX client goes, I usually use VisualVM, which ships with the JDK. From it, you can invoke methods on your MBeans at runtime, or even change their properties.
So the case is the following:
I have an application that communicates with a JAX-RPC web service (Hosted in an .ear package on a JBoss server). We had a requirement of moving all the operations in this web service to a new one with a new name, keeping in mind that we should keep our backward compatibility with clients with the old web service stub. The idea is that I shouldn't keep the logic of the operations in both web services, and instead, try to forward the requests for older clients from the old web service to the new one. I found a solution, but I don't know what are its downsides: I kept the skeleton of the operations in the old web service, and in my ejbCreate(), I created an instance of the bean of the new web service, and now all I do is invoking the operations of the new web service using this bean instance (passing the same arguments as received from the client without running any logic). Is my solution valid? Are there any better alternatives?
why not to use ws-addressing? did you read about it ? (honestly I never used it, but I know it can be used to proxy requests)
Old thread, but here is a better answer for fellow googlers:
Check out membrane-soa reverse proxy: http://www.membrane-soa.org/reverse-soap-proxy.htm
To solve the exact problem in question check this doc: http://www.membrane-soa.org/service-proxy-doc/4.0/soap-quickstart.htm
We're building some Java objects that are exposed via BlazeDS to our flex client application. So basically the BlazeDS messagebroker servlet instantiates and invokes methods on these objects in response to client requests. Works great.
We're using app server-based authentication and have set up a security constraint on the <destination> elements in the remoting-config.xml file element to prevent unauthenticated clients from being able to access these remote java objects. Again, works fine.
However, there are several places within the implementation of these java objects where we want to get the currently logged on user's username. Right now we are doing this via FlexContext.getUserPrincipal(), which gives access to this but we have a nagging concern that we don't like the idea that the implementation of these objects (the service layer) has a hard dependency on a BlazeDS class. But we're not sure how else to get access to this. The same applies to accessing the ServletContext and such.
Any ideas?
There isn't a way around this when using BlazeDS's MessageBrokerServlet. The only option I can think of is to write your own servlet that does AMF, like this one.