[Esapi-dev] [Esapi-user] Fwd: ESAPI development process

[Jim Manico]

This is good feedback - I'm tracking it at
http://code.google.com/p/owasp-esapi-java/issues/detail?id=154

Thanks Sebastian!
- Jim

-----Original Message-----
From: esapi-dev-bounces at lists.owasp.org
[mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Sebastian Kübeck
Sent: Sunday, September 12, 2010 8:32 PM
To: esapi-dev at lists.owasp.org
Subject: Re: [Esapi-dev] [Esapi-user] Fwd: ESAPI development process

Am 13.09.2010 07:22, schrieb Chris Schmidt:
>   If we were to roll our own DI container (which we have talked about 
> before) I feel it would be an unwise design decision to keep our 
> configuration in properties files.
Would rolling out your own DI controller conflict
with others such as Spring, PICO, Guice, JEE6?
Maybe using JSR 299 cold help here but I am sure you already thought of
that...

http://www.jcp.org/en/jsr/detail?id=299
> 
> I really feel that our entire security configuration should move to an 
> xml format. There are a couple reasons for this.
> 
> 1. Through XML we can specify a definitive and enforceable schema for 
> the security configuration, which in turn would aid in allowing a 
> central security configuration to be managed for several ESAPI 
> implementations across various platforms.
> 
> 2. XML configuration allows us to be much more descriptive in our 
> configuration declarations.
> 
> So what I envision is something more like:
> 
> <security-configuration>
> <access-controller name="CustomerComponent" default="true">
> <bean class="com.xyzcorp.security.ESAPISpringAccessController" 
> singleton="true">
> <option name="hoursOfOperation" value="07-19" />
> </bean>
> </access-controller>
> </security-configuration>
> 
> -or if we are using an external DI container (ie Spring)-
> 
> <security-configuration>
> <access-controller name="CustomerComponent" default="true">
> <bean ref-id="CustomerComponent" context-config="spring-acl.xml" />
> </access-controller>
> </security-configuration>
> 
> This gives us a great amount of flexibility in configuration but also 
> allows us to have a enforcable validation policy through use of a XML
Schema
XML-Validation is a good thing but only part of the story.
It would be cool if there was an additional test that checked
the configuration for dependencies.
For example if you have a reference to a class, it would check if the
class exists and this before you launch the application server.

Another thing that would be cool would be to split HTTPUtilities.
A quick look at the documentation shows that this interface
is a case of excessive SRP* violation...

 * The HTTPUtilities interface is a collection of methods that provide
additional security related to HTTP requests,
 * responses, sessions, cookies, headers, and logging.

-Sebastian Kübeck

* The Single Responsibility Principle is one
  of the oldest and most respected design principles...

http://www.objectmentor.com/resources/articles/srp.pdf

> 
> On 9/12/2010 9:16 PM, Kevin W. Wall wrote:
>> Jim Manico wrote:
>>> Good stuff.
>>>
>>> So for
>>>
>>> ESAPI.accessController( "CustomerComponent" ), the CustomerComponent
string
>>> would be defined in the ESAPI config like
>>>
>>> CustomerComponent=com.beef.BeefAccessController?
>> Something like that. If we are still using Java properties files for
>> ESAPI configuration rather than XML, I'm guessing that it rather
>> would be something like:
>>
>> 	AccessController.CustomerComponent=com.beef.BeefAccessController
>>
>> so that the DI would know to apply this to the access controller
component
>> and not some other component such as (say) the authenticator component,
sonce
>> one might equally well have
>>
>> 	ESAPI.authenticator( "CustomerComponent" )
>>
>> However, the exact details will obviously be dependent on the
implementation.
>>
>> Chris and I have had a few off-list exchanges on this topic as well, but
because
>> of Chris' involvement in AppSec USA, we've not yet done any deep dives on
this.
>> Mostly, I think we are waiting for 2.0 to be officially released before
we
>> do that.
>>
>> -kevin
> 
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
> 

_______________________________________________
Esapi-dev mailing list
Esapi-dev at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-dev