[OWASP-ESAPI] Auth

James Manico jim at manico.net
Mon Feb 4 11:09:02 EST 2008


>  Currently, there is a lot of duplication between User and Authenticator,
which has led to bugs (e.g. an Admin trying to log out a user ends up
logging himself out).

Unless your Authentication mechanism is driven fully by the persistence
layer, an Admin cannot log out another user. By design the J2EE Servlet
specification will not allow cross-session communication.

In particular, unless the programmer makes a persitance layer verification
every time controller code checks if a user has a certain role or checks if
a user is currently authenticated (which belong at the top of every
endpoint), then the programmer has no way to effect or verify the data of a
session for a different user. But if the entire Auth/Access control layer is
pushed to the database/persistence layer, then an admin function could just
make a role change or even log out a user by forcing a database change that
will take effect the next time the user hits an endpoint.

I would even dare say that placing all User role/auth information solely in
the session at login time is a security anti-pattern.

- Jim

Hi Jeff, list*

I am busy updating the esapi code to use the * interfaces wherever
possible, rather than hardcoding use of particular implementations.

One place that I have encountered differences between what is
implemented (and used) in the concrete class, vs what is defined in the
interface, is the Authenticator class.

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?

I can understand that you don't want to tie ESAPI too closely to web
applications, so maybe it would be inappropriate to add these methods to
the IAuthenticator interface.

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?

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.

Currently, there is a lot of duplication between User and Authenticator,
which has led to bugs (e.g. an Admin trying to log out a user ends up
logging himself out).

What do you think?

Rogan
_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080204/307e7cb5/attachment.html 


More information about the OWASP-ESAPI mailing list