[OWASP-ESAPI] Question about Provider/Implementation architecture

Boberski, Michael [USA] boberski_michael at bah.com
Thu Aug 13 08:41:06 EDT 2009

Something provider-like that could for example be easily implemented using PHP. Not proposing shoehorn ESAPI into JCE framework.

E.g. take the JCE spec and bend it for our purposes to look something something like:

      How Provider Implementations Are Requested and Supplied
      Installing Providers
THE APPLICATIONDATA CLASS <-- verification parameters below would be associated with this class
      Verification Parameter Specification Interfaces and Classes
            The VerificationParameterSpec Interface
            The PositiveValidationParameterSpec Class
            The MySQLEscapingParameterSpec Class <-- parameters = data policy, not just input validation
      The VerificationParameters Class
      The VerificationParameterGenerator Class
      Pattern Interfaces
      Pattern Specification Interfaces and Classes
            The PatternSpec Interface
                  The DateSpec Class
                  The InputSpec Class
                  The NumberSpec Class
                  The FileNameSpec Class
                  The ValidRedirectLocationSpec Class
      The PatternFactory Class
      The ValidatedDataGenerator Class
      The EscapedDataGenerator Class
      Pattern Management
            Patternstore Location
            Patternstore Implementation
           The PatternStore Class

Mike B.

-----Original Message-----
From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Kevin W. Wall
Sent: Wednesday, August 12, 2009 8:25 PM
To: Rogan Dawes
Cc: owasp-esapi at lists.owasp.org
Subject: Re: [OWASP-ESAPI] Question about Provider/Implementation architecture

Rogan Dawes wrote:
> Jim Manico wrote:
>> And for what it's worth, I think it would be rather easy to do. We 
>> just need a master interface that excapsultates the functionality of 
>> the sub-providers that we already have, and then support...
>> *ESAPI.addProvider(new com.your.company.ESAPI());*
>> Then when you implement *com.your.company.ESAPI* it will have to implement the master ESAPI interface....
> How is this different to (better than) the current:
> ESAPI.setEncoder(new com.yourcompany.Encoder());
> for the bits you actually want to implement yourself?
> all addProvider would do is:
> public void addProvider(Provider provider) {
>     setEncoder(provider.encoder());
>     ...
> }
> but provider would have to have implementations for EVERY ESAPI 
> interface, even those where you just want to use the reference.
> Doesn't seem like an improvement to me.

Before I make a judgment, I'd like a clarification as to what *exactly* Jim is referring to. Specifically Jim, are you referring to is a provider that conforms to java.security.Provider or something simply "provider-like"?

Recognize that java.security.Provider requires some very specific expectations (see
In particular, there is some expectation of providing an SPI (service provider interface). And then there's the question does it need to integrate in with the rest of the Java security providers? E.g., 1 reqt, as per the above URL:
    static EngineClassName getInstance(String algorithm)
        throws NoSuchAlgorithmException

    static EngineClassName getInstance(String algorithm, String provider)
        throws NoSuchAlgorithmException, NoSuchProviderException

    static EngineClassName getInstance(String algorithm, Provider provider)
        throws NoSuchAlgorithmException

where EngineClassName is the desired engine type (MessageDigest/Cipher/etc). For

    MessageDigest md = MessageDigest.getInstance("MD5");
    KeyAgreement ka = KeyAgreement.getInstance("DH", "SunJCE");

return an instance of the "MD5" MessageDigest and "DH" KeyAgreement objects, respectively.

Furthermore, I think the intent of providers is somewhat different. If you are providing a Provider (sorry) implementation, you generally are expected to provide EVERYTHING needed and not just selectively (say) writing a single piece such as (for ESAPI) an Encryptor or a Validator. In that sense, I agree with Rogan. I think very few are going to be willing to do that. Unless ESAPI is successful beyond our wildest dreams, we are not going to get the ESAPI equivalents to providers that JCE did (Bouncy Castle, Cryptix, IAIK, etc.). A large part of the reason that they were so successful is that 1) Sun provided a rather skimpy set of crypto algorithms, 2) the Sun implementation was not originally open source, and 3) the US export restrictions at the time were quite draconian. Those things together drove the open source community to provide numerous implementations of Sun's JCE. (That plus Sun
*did* define an SPI as well.)

Also, if Jim means "provider" in the sense of java.security.Provider, note that java.security.Provider
	"class represents a 'provider' for the Java Security API, where
	a provider implements some or all parts of Java Security."

As far as that goes, I would argue that what OWASP is doing with ESAPI is not so much _Java_ security as _Application_ security. That is not to say that much of this is lacking from the JDK. It is, but I don't think that's how Li Gong envisioned _Java_ security and its whole security model.

Now if Jim is referring "provider" as simply a way to repackage and/or re-factor things to make it so the ESAPI reference model is easier to replace with one's own implementation, I can _ALMOST_ support that.
(I already support it in principal, but you all know the difference between theory and practice. :) I *would* have a problem is implementing one's own ESAPI "provider" meant replacing the whole reference model though. I just don't see the value in that (unless we have the incentive to do a crappy job, but obviously that's NOT the case).

Anyhow, those are my thoughts. Perhaps if Jim or Mike Boberski could give me a bit more context and perspective I'd be able to make more rational arguments.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org

More information about the OWASP-ESAPI mailing list