Talk:ESAPI Specification

I tried to keep the specification as compatible as I can with the existing APIs, however there are definately places where existing users are going to have to modify their code - specifically where it deals with Encoding and Validation. I believe these changes are absolutely necessary however to establish a good cross-platform specification. I also believe the migration path allows for the smoothest transition for end-users (developers) to make the necessary changes without completely breaking their existing implementations. This is similar to the path that Spring-Security took with it's 2.0 -> 2.5 -> 3.0 path where they did a very similar thing and I used their experience as the basis for the proposed roadmap.

--Chris Schmidt 02:23, 16 June 2011 (EDT)

Proposed Roadmap

Does this seem like a realistic and smooth approach?

--Chris Schmidt 02:26, 16 June 2011 (EDT)

AccessController

Let's start with discussing the proposed changes to the AccessController.

Summary of proposed changes:

• Drop deprecated methods isAuthorizedForXXX, assertAuthorizedForXXX
• Replace (Object) Parameters with strongly typed StereoTypes

Thoughts?

--Chris Schmidt 02:26, 16 June 2011 (EDT)

I like the resource approach, I am imaginating there will be, lets say, a FileResource inheritated from Resource, so if a FileResource is passed to the method then only assessments against file resources will be done, am I right?

--Juan C Calderon 19:23, 16 June 2011 (CDT)

That is correct, however you could also have more complex resource types that integrate with a complex context object to create a context-based access control rule as well. This is an API that I have been silently working on (from a design standpoint) for the better part of a year so I am anxious to hear everyone's thoughts. The concept is simple - I want an API that can handle a simple Role-Based Access Control decision, a Data-Access Control Decision, and a Context-Based Access Control decision all with the same signature. I found this solution to be both elegant and simple to implement and use.

--Chris Schmidt 01:36, 17 June 2011 (EDT)

Logged in user, from where?

where is the logged in user information will come from? how is it going to be available for isAuthorized?

--Juan C Calderon 19:16, 16 June 2011 (CDT)

I personally like the Spring-Security approach - which is similar to the way ESAPI for Java currently does it - in that it uses a threadlocal; however - afaik there is no concept of ThreadLocal variables in PHP or ASP.Net. I think the best way to do this would be to borrow the concept of the SecurityContextHolder from the Spring-Security model and leave the actual implementation of how it is populated up to the implementation. So this would be a new interface called something like AuthenticationHolder or UserContextHolder with a method to getCurrentUser() which would return the currently logged in user.

--Chris Schmidt 01:32, 17 June 2011 (EDT)

@Chris, I think what Juan was wondering--and if not, it is certainly something that I am wondering--is where will the user's credentials be provided to ESAPI. Once the user has authenticated, this approach of using ThreadLocal works fine. (I think Posix threads have a similar concept, so PHP on Posix systems may be able to leverage that. Not sure about ASP.Net.) However, the whole point is that either you need to provide some additional framework classes (make similar to the JAAS approach with login call backs) or add some additional specified methods I think. For example, in ESAPI, we also have login(ServletRequest req, ServletResponse resp) that allows collection of user name and password from a user via an HTML form or HTTP Basic or Digest Authentication, etc. If all that is provided is a no-args login() method, then how is the user initially authenticated.

In addition, as we drill deeper into Authenticator, I would like to see use deal with a more general Credentials abstraction rather than assuming everything is a string-based password. We can then subclass to get a Password class.

--Kevin W. Wall 23:28 , 18 June 2011 (EDT)

Exceptions

The specification looks very "Java", that is, I am not pretty sure if you can handle structured exceptions in PHP, in Classic ASP is not possible, yet it could be emulated a little. Can we come to a representation that is more language neutral? (this is not a show stopper, just thinking on trying to be the more neutral possible)

--Juan C Calderon 19:21, 16 June 2011 (CDT)

I added this at the very end because it does feel very Java'ish to me as well. However, that being said - all of the languages have a concept of either an Error or an Exception. PHP has Exceptions and as far as I can tell in ASP.Net you can raise an Error event which accomplishes the same task. Unfortunately in modern OO languages the concept of Error has a completely different meaning than an Exception as we are using them. An error is generally a condition that cannot be recovered from whereas an Exception represents a state that can - hence the use of the Exception word.

--Chris Schmidt 01:32, 17 June 2011 (EDT)