Ken Maruyama

Greenhorn
+ Follow
since Apr 29, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ken Maruyama

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.
13 years ago
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

13 years ago
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.
13 years ago
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 all the time.
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 called 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!