J2EE security through entire enterprise app

[Dana Hanna]

Wow - crack your knuckles - this is a big question.
I'm developing a large scale J2EE web based application contained completely inside of JBoss 3.2.x. My application consists of the following layers:
1) EJB 2.0 Entity (all CMP for now, may require BMP later, but unrelated...)
2) EJB 2.0 Stateless Session Facade using serializable client "beans" as input/output
3) "Client side" (servlet container) Service Locator / Client Facade dealing with client bean manipulation and service lookup
4) Servlet based web app controller
5) JSP / tagslibs
(4 and 5 - MVC - possibly struts)
All activity in this app travels up and back through those layers. That's not the problem, everything is beauuuutiful.
I'm at the point now where I'm defining security. There are several points of security to define.
1) Entity bean protection - these beans should only be accessible by other EJBs. These beans have only the Local interfaces created, and no remote interfaces. Is this secure enough, or should method level, role based JAAS come into play here to authorize only the beans I specify to make method calls or lookup homes.
2) Business "dynamic" Security - single actions such as create user, add user to group, etc... I need dynamic database security here in that users can only add other users to groups they are members of, etc. Should that be defined in the session bean layer (some type of auth would have to be passed in, or accesible), or assume that it was handled by the calling "layer" (the ServiceLocator / Client Facade). It would require some type of synch with the web session to confirm the user, so it would have to be done in the servlet engine, or something passed in about the caller. Don't tell me to use Stateful Beans, they are the devil, and are not meant for this purpose. Ideally this would occur using JAAS and having the roles for the principal loaded from the DB - see #4
3) The exposed Remote Stateless Session Beans need security (unless above security was chosen to be passed in). This could be JAAS role based security in which the web app authenticates through JBOSS JAAS support and internally manages those permissions, or as mentioned above, some user object passed in whose password (plain text or encypted?!?!) is confirmed...
4) Retrieving and validating user PW. I'm set on storing this in the DB digested using MD5 or similar algorithm. No problem there, but at what layer is the "digesting" appropriate? One side of me says do it ASAP to avoid having clear text passing around, but another side tells me to put it farther down, possibly in the SS EJB to make calls to it more simple. If the MD5 were done at the servlet level, it would have to call all the way down to get the real PW, come back, then compare digests, then continue. Comparing at a later time could prove more efficient, and participate in any transactions nicer... Encororating JAAS and having the "roles" for the principal loaded from the ejs would be an ideal solution (for use in the dynamic business rules.. see #2 , but is this proper usage? How would I implement such a strategy?
I realize that a lot of this is totally opinion based, has many different answers, and is a VERY advanced topic. I'm just curious if anyone else has experienced similar design issues and how they were overcome. I can't be the only person doing this...
As always, thanks in advance!
Locuester
[e-mail]
[ February 28, 2003: Message edited by: Dana Hanna ]

[Dana Hanna]

No answers? C'mon security buffs, eat this one up!

[JeanLouis Marechaux]

Dana,
I think there is no answers to your questions, 'cause each application needs a specific security policy.
Nevertheless, I'll try some hints.
1) According to me, if your entity beans really need to be protected, local interface is not enough. One day, maybe you'll need a remote interface on one of them, and then all your security will be cracked.
But I guess you can add method security, with a specific J2EE role never mapped to a real user/group.
The EJB delegation model (run-as) can allow you to give this role only to the calling EJBs
2) At the first glance, the J2EE role architecture should answer your needs here, handled by the client layer. This is one option, but it really depends on what you are trying to do. If your authorization rules are really specific, you'll be way out the J2EE security spec quickly, so you 'll have to implement your own mechanism to handle "the dynamic security" you are talking about.
Note that for a specific user, you always know whitch role he is part of.
3) same as 2
4) I don't understand how using the decryted pwd can be simpler. If you can deal with digests only, then do it. The less you manipulate decrypted passwords, the better it is for you security, no ?
I do not know about jBoss, but some application servers allow to use SSL within the app server (rmi), and also between the app server and the security registry (ldap, db). So that even if your pwd is decrypted, it is alway protected by a SSL protocol