aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Client Side Authentication Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Client Side Authentication" Watch "Client Side Authentication" New topic
Author

Client Side Authentication

Alan Peltz
Greenhorn

Joined: Dec 12, 2003
Posts: 20
I have a message driven bean that I want to call a session bean from. The problem is I don�t know how to authenticate the user because the session bean is protected by JAAS. The message driven bean is called by a different session bean, which is authenticated. So, is it possible to pass a principal or a user-id and password to the message driven bean and from there call something that authenticates us?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
I don't understand your question...
MDBs are messsage consumers that listen to a Queue or Topic. They can never be directly invoked by any code and therefore no security credentials can be propagated.
[ February 26, 2004: Message edited by: Chris Mathews ]
Edy Yu
Ranch Hand

Joined: Nov 21, 2000
Posts: 264
Agree with Chris ...


SCJP, SCJD, SCWCD, SCBCD, SCEA, IBM Certified Enterprise Developer, WebSphere Studio V5.0
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Client's security context is not propaged to MDBs.
Using <security-identity> tag for MDBs, you can propagate a constant role to the Session bean. All beans being called from the onMessage() method of the MDB will have the same role propagated. I am not sure if this would help you :roll:
Alan Peltz
Greenhorn

Joined: Dec 12, 2003
Posts: 20
Thanks for the replies, all! I will go into a bit more detail, so that it makes more sense. This is how it is set up � it may seem like madness, but there is reasoning behind it (which I won�t go into):
We start out with an authenticated user invoking a method in SessionBean1. SessionBean1 sends message to queue -> MDB1 picks up message and calls SessionBean2, which is in a different application and is not protected by security. -> SessionBean2 sends a message to queue -> MDB2 picks up message and calls SessionBean3. -> SessionBean3 is protected by security and the remote interface cannot even be created because we have no principal.
Vish, I think you are onto something. I'll try to research it a bit. If anyone has any examples of this being done, that would be very helpful. If I get anything working, I will post what I did.
 
Consider Paul's rocket mass heater.
 
subject: Client Side Authentication