How to get information about a user in a stateless session bean
I am working on an existing j2ee application and have to remove some vendor specific method calls from the code.
Daos behind the session facade makes calls to the ejb container to get the user ID and password to connect to the database. The original user ID and password that is used to connect to the server.
I can get the user id with sessionContext.getCallerPrincipal()
Is there anyway access to SECURITY_CREDENTIALS
used in server connection or is there a way to pass information from server connection to ejbs (they are all stateless session beans).
This is a large application with a rich client and web interface, and in a perfect world, I would be happy to go back and rebuild the whole solution to use J2EE security, etc., but unfortunately this is not realistic.
source to share
I can't give you a general solution, but this is what worked for us. We have an application server that connects to LDAP as a specific user who has the ability to prompt for credentials for other users. We then have some generic security code that we can use to request user credentials within session beans based on the identity of the users when they first logged in (just like you do it through getCallerPrincipal()
).
We also put the user ID in a thread local variable so that classes down the call chain from the EJB do not need to be "container aware". They just access the id from the local thread and use the security classes to find the user's profile information. It also makes it easy to modify the implementation for testing, or even something other than an LDAP lookup.
Another convenience we created was JDBCServiceLocator
one that fetches user / password connections for the current user. Thus, the developer does not need to explicitly code security searches at all.
source to share
Normally, the Java EE security model does not allow retrieving the user's password for security reasons. But it depends on the implementation. Some vendors provide methods for obtaining this information, but if you rely on such implementations, be aware that the portability of your application will be compromised.
One common approach is to write a servlet filter to intercept the login request and keep a copy of the credentials to be used later. If your application does not use the Java EE security framework, this can be easily implemented. This is because some vendors discourage filtering authentication servlets.
source to share