geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nash Foster <>
Subject Re: J2EE security
Date Tue, 12 Aug 2003 13:21:50 GMT
Edward Flick wrote: 
> >
> > > 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.



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

View raw message