[OWASP-ESAPI] Differences between IAuthenticator and the concrete implementation

Jeff Williams jeff.williams at owasp.org
Mon Feb 4 23:17:36 EST 2008

Hi Rogan,

> Authenticator defines getCurrentRequest() and getCurrentResponse() 
> methods which are used by the concrete User class. However, these 
> methods are not defined in IAuthenticator.
> Is this by design, or just omission?

The use of threadlocal for request, response, and user is by design.
I wasn't sure that every implementation would have this. But now
I'm convinced that it's really useful. Even JSF has added a static
way to get the current request from anywhere.

The static accessors need a place to live. I thought the Authenticator
made sense, since mostly you use them for authentication/session
purposes. So I think making these available in the ESAPI "locator"
class would make sense.

The reason they're not in the interface is they're not really required
to implement. But they really are, since ESAPI doesn't really pass
around the request or response at all anymore.

> Maybe it would be more appropriate to just have a getter and setter for 
> the "lastHostAddress", and let the particular IAuthenticator 
> implementation set that when it authenticates the request?

I'm not sure what you're getting at here exactly. There are getters
and setters for lastHostAddress, but they're protected. For anyone following
along...lastHostAddress is used to detect IP address jumps.  You can set
a threshold on this in the IntrusionDetector.

> Following this logic, in my opinion, User could/should be a simple data 
> object that doesn't implement any real functionality itself, but rather 
> delegates to the current IAuthenticator implementation to do any actual 
> work. Then implementors of custom IAuthenticators would not need to 
> implement a User class, but could simply make use of the one provided.

For actions that are performed directly on users, like lock(), enable(),
changePassword(), logout(), etc.. I think they should be in the User
class. The Authenticator class is for methods that aren't associated
with a single User. Hmm... perhaps login() and logout() should be rethought.
Also, some reorganizing on the methods in Authenticator
between User and ESAPI based on moving the ThreadLocal stuff makes sense.



More information about the OWASP-ESAPI mailing list