[OWASP-ESAPI] Question about Provider/Implementation architecture

Jim Manico jim.manico at owasp.org
Thu Aug 13 06:00:58 EDT 2009


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

This is what I'm aiming at. I just figure that once you have your set of 
ESAPI classes set up for your shop - even if most are just the reference 
implementation, and only your access control and authentication piece are 
custom (like I do), then if would be handy to have the optional "bundling" 
configuration option described below.

> (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).

I think it's crazy to re-write much of the reference implementation - 
especially the encoder and httpUtilities. I don't expect many users of ESAPI 
to go that route. But I do expect almost everyone to build their own 
authenticator, at least...

.. yea, replacing the whole reference module is a lot of work - but it 
certainly is an option for large shops. At the end of the day, ESAPI is just 
a set of interfaces....

- Jim

----- Original Message ----- 
From: "Kevin W. Wall" <kevin.w.wall at gmail.com>
To: "Rogan Dawes" <lists at dawes.za.net>
Cc: "Jim Manico" <jim.manico at owasp.org>; <owasp-esapi at lists.owasp.org>
Sent: Wednesday, August 12, 2009 2:25 PM
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
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Provider)
> 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
> example:
>
>    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
> -- 
> 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