In my EJB application, I need to implement a shared security cache, which will be queried by session beans to determine user authorization. Can someone please shed some light on how this could be done? Also, in the future, there might be requirement to go clustering, in that case, how to manage multiple copies of caches?
In this specific case (security/authorization) you should let the container help out. For instance by using a connection to LDAP?
In other cases we implemented a cache outside of the J2EE container, running in a separate JVM.
Joined: Jun 20, 2005
Thank you for the response. Yes, in this case, it is for user authorization. But we need one that can be easily managed/customized such that the system administrator will simple assign user access to different business entities through an administrative UI, and when user later logs into the system and calls session beans, the session beans will need to determine if the user has access on the fly. Since the authorization information is stored in DB, instead of hitting the DB every time, I thought that initially, the authorization information could be loaded from DB and cached. Maybe I am not fully understanding the J2EE declarative security, but I think you'll have to modify the deployment descriptor every time the security configuration is changed and thus will require a re-deploy. So, the declarative security will not meet my customizable requirement. Right?
Also, I am interested in the cache that is outside of the J2EE container, could you please provide some more details? Is it still running under the J2EE server? If not, how does it get managed? How does the EJB interact with the cache? What happens if multiple EJBs do read/update at the same time to the cached object? Any lock?
Maarten de Heus
Joined: Jan 30, 2006
With authorization the idea is that you assign EJB method permissions to groups. Your system administrator can then create new users and place them into those groups. No need to redeploy your EJB's because the groups are stable.
In the deployment descriptor of your EJB use the <method-permission> tag to tell the server which roles are allowed to call which methods. For the roles you specify groups and not specific users. You then map the groups specified in the <method-permission> tag to real groups/principals you created in your J2EE server. This mapping is not specified in the J2EE spec so how this mapping is done, depends on the specific server you are using. In Bea WebLogic the mapping is done in the WebLogic specific deployment descriptor (weblogic.xml).
As for the external cache implementation. The J2EE spec. has some demands for the bean developer about not interfering with the container. Some of those demands: No messing about with the classloaders, do not use native libraries, do not use static variables. In cases where we were asked to break those demands, we created a separate JVM running the law-breaking code. We connect to the other JVM using RMI.
Most caching mechanisms are implemented using some Singleton pattern. (static variable which is also a nono). Run the cache in a separate JVM and connect via RMI. Do NOT implement the cache yourself but use some framework like JCache. The framework will handle the multiple calls.