Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

J2EE security through entire enterprise app

 
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
dana@deepsnow.com
[ February 28, 2003: Message edited by: Dana Hanna ]
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No answers? C'mon security buffs, eat this one up!
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
After some pecan pie, you might want to cleanse your palatte with this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic