[Esapi-dev] ESAPI4J Reference Implementation Extensibility

[Brent.Shikoski at acuity.com]

First off, I'd like to thank the ESAPI developers for all their hard work, 
I definitely know it will help my company create more secure applications 
than we would be able to do by ourselves.

I've been working on a security library for my company built around ESAPI 
for use in our applications.  As I've tried to bend it to my will (maybe a 
bad idea), I've come across a few challenges.

I was wondering if the intention was to make the reference implementations 
extensible or not.  There is a lot of good code in there and I would 
rather use your code rather than write my own.  Two things that I've spend 
some considerable time on are the User and SecurityConfiguration 
implementations. 

I have a need to change some of the behavior of the DefaultUser, but not a 
lot.  The DefaultUser class is not now extensible by classes outside of 
the package, because of the constructor.  What I ended up doing was 
copying (cringe) the code from DefaultUser and creating my own abstract 
class that I then extended.  Unfortunately I can't use composition either, 
because DefaultUser can't be instantiated by my code and I believe 
currently only created by the FileBasedAuthenticator, which I'm not using. 
 Actually, I did a similar thing with the FileBasedAuthenticator, which 
has a lot of useful code that any authenticator class would need.

The other thing I've wanted to do is control how the ESAPI.properties and 
validation.properties are being loaded.  I'd like to do this so I could 
provide a "standard" configuration to applications that then could add and 
override some of the properties, but not in the same file.  I also would 
like the ability to be able to load properties from places other than a 
file (possibly a database?).  The DefaultSecurityConfiguration class is 
extensible and it can be made to load resources differently by over-riding 
the getResourceStream(String) method, however it probably isn't advisable. 
 The constructor calls the private loadConfiguration() method, which would 
be nice to override to do what I want, but constructors shouldn't call 
methods that can be overridden, so being private is appropriate.  The 
loadConfiguration() method then invokes the  getResourceStream(String) 
method, which can be overridden, but is generally a bad idea.  I did see 
that Issue #86 (
http://code.google.com/p/owasp-esapi-java/issues/detail?id=86) addresses 
at least in part what I'm trying to accomplish.

If I did want to create my own SecurityConfiguration implementation and 
register it with the ESPAI class, there is a bit of an issue there too. 
Because when the ESAPI class is loaded it automatically creates an 
instance of DefaultSecurityConfiguration and if it can't locate the 
property files it throws a NullPointerException, which in turn makes the 
class loader throw an ExceptionInInitializerError and the ESAPI class 
can't be loaded.  Now, maybe that is exactly what is intended, but for my 
part it's a requirement I'd rather not have.

I realize that creating classes for extensibility is difficult, the things 
that I would want to override are different than want someone else would 
want.  It also makes some changes more difficult or impossible without 
breaking other people's code.

If the reference classes aren't meant for extension I'd suggest that then 
be made final so that developers like me get the hint.  If that is the 
case, I'd like at least be able to more easily create composition classes 
that can delegate some functions to the references implementations.  There 
is good code there and I'd like to leverage it as much as possible.

Wow, sorry I wasn't able to make it more concise, hope I wasn't too 
confusing.  I also realize there may be good security reasons why these 
things are the way they are, I'm definitely not incredibly knowledgeable 
about such things.  If I can be of assistance in any way let me know.  If 
I'm clueless and full of it, well maybe keep that to yourself.

Brent

 
  
<br><br>This e-mail is confidential.  If you are not the intended
recipient, you must not disclose or use the information contained
in it.  If you have received this e-mail in error, please tell us
immediately by return e-mail and delete the document.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100115/30711c99/attachment.html