• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is CallBack Handler called by the same Thread that handles request?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I have a situation where a web application is calling some JAX-RPC web service.
My program will inject the Username Security Token by calling a javax.security.auth.callback.CallbackHandler class that I made.

I will like to use the userid/password that is visible in the request object.
When the CallbackHandler method is called, the request object is not visible in the method.

I'm trying to figure out how to access the userid/password within the CallbackHandler, that do not have access to request object (or session).

I think I have a solution, but not sure if it works in all conditions.
If anyone can give me input on the validity of this method it will be great.

Here is my solution:

In the CallbackHandler object that I created, I put a static HashMap object that will (should) stay persistent on JVM.
When the application is handling the request from a user, (The request object is visible) I put the userid/password in the static HashMap using Thread.currentThread().getId() as a key.
When the CallbackHandler is called by my web application server, (request object is not visible) I retrieve the userid/password from the HashMap again using Thread.currentThread().getId() as a key.

The idea behind this is that when a request is made to a web app, each request is handled by single thread per request.
Therefore the Thread id can be used as a key even when the callback handler is invoked by the application server (Not directly by my code) automatically behind the scene.

This should work if the callback handler is guaranteed to be invoked by the same thread.
But I'm not sure if that is the case.

I use IBM WebSphere application server 6.1.
Servlet 2.4
Java 1.5

My small scale test indicates that it works.
However if anyone can give me any input on this it will be great.

Thank you in advance!

P.S. I moved this post from another thread. This thread is probably more appropriate.
 
Ranch Hand
Posts: 489
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

This should work if the callback handler is guaranteed to be invoked by the same thread.
But I'm not sure if that is the case.



It's difficult to tell without seeing a lot of code.

But here are a few angles you would like to think of - what prevents that static HashMap from growing indefinitely?
Is this CallbackHandler part of a framework? If it's homegrown why dont you pull the data from the request and set it on the CallbackHandler (probably in a constructor) so that it's methods have access to the data?

cheers,
ram.
 
Ken Maruyama
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ram, thank you for the reply

what prevents that static HashMap from growing indefinitely?



It will be my program's responsibility to delete the object from the HashMap, before the request closes.
I do something like this:



Is this CallbackHandler part of a framework?



CallbackHandler is I believe part of JEE specification. To be specific I believe it is JSR109.
However it looks like IBM extended it and has it's own implementation.
The call back handler is defined in a file "ibm-ebservicesclient-bnd.xmi".

The instance in constructed by the JEE framework, not from my code.

I looked at JSR109 specification document, but wasn't clear if the call back handler is always called by same thread or not.

However since the web service is called synchronously, not asynchronously, to me it doesn't make sense for the application server to invoke the call back handler in a different Thread.
In that case the invoker will be just sitting there waiting for the other Thread to end the process.

FYI here is the code for the call back handler

 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

CallbackHandler is I believe part of JEE specification. To be specific I believe it is JSR109.
However it looks like IBM extended it and has it's own implementation.



It's part of the JAAS api. I asked only because your question was about web services invocation and I did not find any mention of JAAS anywhere.

Look at this constructor.


This is what should be used while using JAAS in a login authentication flow. I havent worked with JAAS and WS, but I dont think it should be different.

ram.
 
Ken Maruyama
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for the reply again,

It looks like Callback Handler is part of JAAS but also a generic class that can be used by different security/authentication services.

In my case I think it is part of JSR109 that is invoking the handle() method.

The constructor



is never called in my code.
It is automatically called by the JEE container, which I believe is acting according to IBM enhanced JSR109 specification, which is designed to apply (inject) security information when JAX-RPC is used to invoke web services at the client side.
It is challenging because I can't pass values in a normal way you pass information to another class.

If there is a way for my code to construct the object (passing id/pass), and make that instance be used when JAX-RPC is used to invoke web services, I think that will be more appropriate way of doing it than the way I do with Thread ID. I will not have to worry about different thread running the callback handler in this case.
 
reply
    Bookmark Topic Watch Topic
  • New Topic