[OWASP-ESAPI] Question about Provider/Implementation architecture

Kevin W. Wall kevin.w.wall at gmail.com
Wed Aug 12 20:25:17 EDT 2009

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
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,

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

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

More information about the OWASP-ESAPI mailing list