Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Client Side Authentication

 
Alan Peltz
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with Chris ...
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic