Edward Flick wrote: > > http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Architecture > > > People interested in guiding and assisting me , > > > please respond.
>>From the Wiki: > Open Discussion > All three of these provide data integrity and confidentiality. I > personally like SASL the best out of these as you aren't exposing your > Subject to the auth mech and the wonderful SRP mechanism is > implemented by several providers. SSL should decorate this project at > some point, but I really think that initial SASL support is > imperative. Also, just so you know why I like SRP so much: it is > essentially an unsniffable (discrete log security) drop in replacement > for username/password plaintext. So essentially you get the ease of > User/Password plaintext without the dictionary attacks, spoofing, > replay attacks, offline attacks, etc. What do you guys think? Just out of curiosity, are you planning on using the Sun reference implementation of JAAS or rolling your own? If the later, definitely build a plain-text password scheme first--it'll be easier to test and verify the architecture that way. Other than that SRP seems like a reasonable next step. I'd love to be able to use existing user management tools like Active Directory, Entrust, or ACE to handle user setup, configuration, and authentication. So, I'd suggest building one solid and secure mechanism into Geronimo and then spend effort integrating other Enterprise authentication services so he can play nice with others. Definitely a differentiator in the Enterprise. On Mon, 2003-08-11 at 09:15, Prashant Bhatt wrote: > 1) Specification: Understand the Specification properly. This will include > both > the J2EE security issue and the stand-alone security issues. My experience > with > J2EE security has not been good. I'am sorry to say that , but it's true that > the > spec isn't smart on all these issues and is preety silent on the client > containers contract. This is great; we should also try to understand where the specification is deficient and implement the "right thing" there. For example, while J2EE specifies a declarative deploy-time access control system, I'm not aware (which may be me, of course ;-) of any J2EE standard for making run-time access control decisions. Geronimo should provide a reasonable implementation for this until the specification catches up. > So let's understand the specification first. I shall go ahead and be > accountable. Shouldn't the entire dev team be responsible for knowing the specifications? ;-) > 2) Look at the current status. Security is a very distributed area (The whole > J2EE is..) . It's imperative for us to understand where the project currently > stand. Right now I see only webcontainer and verifier being talked about. > Some > one has to make a sense out of all this. One place to start looking is for problems with other containers. JBoss is pretty promiscuous about what it'll deploy in a default configuration (if you learn how to tickle it). Weblogic is notorious for exposing functionality used by developers during testing; though that may be a Jetty / Tomcat issue. Several containers have terribly week session management schemes. Geronimo should avoid all these issues, to the extent possible. I have a pretty good list of the "essentials" for an application server. I'll see if I can break it free of corporate and get some data posted. > Please take this accountability and document the relationship with different > components. It'd be nice to have permissions and roles differentiated in the "kernel". The Unix "root is god" model really bites when it comes to handling the inevitable server compromise. > 3)UseCases: Try and make as many possible. This is most interesting. I can think of dozens. How should they be documented for best effect? If no one has any preferences, I'll just start sending e-mails. ciao, -nash *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. ***********************************************************************
