File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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

Win a copy of Elasticsearch in Action this week in the Big Data forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Client Side Authentication" Watch "Client Side Authentication" New topic

Client Side Authentication

Alan Peltz

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: 1066
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

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.
I agree. Here's the link:
subject: Client Side Authentication