[Esapi-dev] ESAPI4J Reference Implementation Extensibility

[Boberski, Michael [USA]]

I can at least partially answer the question with this: http://www.owasp.org/images/8/82/Esapi-design-patterns.pdf

Best,

Mike B.


________________________________
From: esapi-dev-bounces at lists.owasp.org [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Brent.Shikoski at acuity.com
Sent: Friday, January 15, 2010 12:51 PM
To: esapi-dev at lists.owasp.org
Subject: [Esapi-dev] ESAPI4J Reference Implementation Extensibility

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

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/2293bbb0/attachment.html