- Posted by: Kresten M
- Posted on: April 17 2004 14:19 EDT
The purpose of this post is to seek input on ways to make a smarter implementation of a web-apps security model, as the application is moved from pure jsp/servlet to an ejb based solution. Ill just start out with a quick overview of the application.
The system is basicly an intranet consiting of a bunch of different modules like bug database, user management/training tracking, procedure database, announcement/news systems and the like used in a volunteer organisation known as ARK. Because its a volunteer org. with quite loose structure its not possible to just place users in a role, like management, bug administrator etc (or at least that would require a ton of roles to be defined).
Our current code works with having each "function module" (which could be "bug management") have its own certificate, users can then have a certificate to that group/module. The certificates contain boolean flags like "can see bugs", "can add bugs", "can modify training status" etc. The modules have very different flags, and as its a big mix of who can do what, its very hard to make a role based security system. In our current code the servlets load in the certifacates from their different tables on login, and then saves them in the users session.
Moving to a ejb based system, I hoped someone here was able to give some suggestion to how this could be implemented in a smart way. The system is going to be a pretty standard setup, with entity beans to represent our data, and all the "buisness logic" (which is some fairly simply operations) in session beans. The things is that we would like to have the security system not only apply to the webplayer but have it implemented in the session bean facades, so that we are prepared for opening up to rmi based clients (we are using jboss btw).
This post has become a bit messy, but the summary is that I hoped some of you had worked with/seen web applications using a similar security approch, and had an idea as to what structure to follow in the layout of the app.
Thanks in advance
I suggest you re-examine role-based security. Every J2EE server I have worked with allows you to assign a single use to multiple roles. If you define a role for each function module (bugs, management/training, news), and assign each user multiple roles for the modules you can access, you can replicate your "certificate" based approach in a standard way.
Once you are following the standard, you can use the built in features of your server to propogate security credentials from the web layer to the EJB layer (in many cases, this will be automatic).
My company found J2EE's role-based security
insufficient for our enterprise applications. We built our
own instance-level security framework.
The J2EE 1.4 specification contains a brief note about this topic:
J2EE.3.7.2 Instance-based Access Control
Some applications need to control access to their data based on the content of the data, rather than simply the type of the data. We refer to this as instance-based rather than class-based access control. We hope to address this in a future release.
See also: "Instance Based Security in Java"
"If you define a role for each function module (bugs, management/training, news), and assign each user multiple roles for the modules you can access, you can replicate your "certificate" based approach in a standard way."
The problem is that I dont want to give either full or none access to a module. A user might need to be able to use 2 of the functions in that module, and 3 functions in another module etc. Because of the structure of the organisation its not possible to group ppl into roles defining what they have access to, so using roles I would have to define a role for every single function in every module, which I really dont think is the intended use of the system.
Im currently looking at if I can make some custom security info go along with the credentials and combine container and programmatic security. Had just hoped others had been in the same situation and had found some good methods to approch this problem.