[OWASP-ESAPI] Question about Provider/Implementation architecture

Sebastian Hennebrueder usenet at laliluna.de
Tue Aug 18 02:56:12 EDT 2009


Couldn't we solve this with a builder, which can be passed to ESAPI.

ESAPIFactory factory = 
ESAPIFactory.createDefault().replaceValidationr(MyValidator.class).replaceEncoder(MyEncoder.class)

ESAPI.addProvider(factory.build());

Internally, it just does what is happening currently in a step by step 
approach, setting encoder, encryptor etc.

This allows to use just the default and replace whatevery you want.

-- 
Best Regards / Viele Grüße

Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de

Mike Boberski schrieb:
> Jim, understood about the first couple, they weren't necessarily intended to
> match ESAPI conventions. More, placeholders to indicate I wasn't forgetting
> about those types of functions.
> 
> The verification parameters coupled with the application data class are/were
> actually the "meat" of my proposal, to take advantage of a provider-like
> structure/packaging.
> 
> I'll write up a few more details when I'm back in the office.
> 
> Mike
> 
> 
>> On Mon, Aug 17, 2009 at 7:26 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>>>  Mike,
>>>
>>> Let me address just a few of these, to start....
>>>
>>> THE SECURITYAUDIT CLASS = assuming you mean logging? We almost always call
>>> these abstractions "Logger" in the programming world....
>>>
>>> THE CRYPTOGRAPHICSUPPORT CLASS = We call this ESAPI.encryptor()
>>>
>>> THE IDENTIFICATIONANDAUTHENTICATION CLASS = ESAPI.authenticator()
>>>
>>> THE SECURITYMANAGEMENT CLASS = ????????
>>>
>>> VERIFICATION PARAMETERS CLASSES = is a entirely separate conversation
>>> altogether, and implies a very specific kind of data and data validation
>>> architecture.. Do you have a moment to describe this part of your proposal
>>> in a bit more depth, sir?
>>>
>>> - Jim
>>>
>>>  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:
>>>
>>> THE PROVIDER CLASS
>>>       How Provider Implementations Are Requested and Supplied
>>>       Installing Providers
>>> THE SECURITYAUDIT CLASS
>>> THE CRYPTOGRAPHICSUPPORT CLASS
>>> THE IDENTIFICATIONANDAUTHENTICATION CLASS
>>> THE SECURITYMANAGEMENT CLASS
>>> THE APPLICATIONDATA CLASS <-- verification parameters below would be associated with this class
>>> VERIFICATION PARAMETERS CLASSES
>>>       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 <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 (seehttp://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
>>> _______________________________________________
>>> OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
>>> _______________________________________________
>>> OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
>>>
>>>
>>>
>>> _______________________________________________
>>> OWASP-ESAPI mailing list
>>> OWASP-ESAPI at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>>>
>>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi






More information about the OWASP-ESAPI mailing list