Don't worry, I expected some level of resistance to a change of this
magnitude, plus this requires a very different way of thinking so I
planned on having to explain it, I tried to cover everything in the
document, but that's impossible to do :)
This is VERY similar to the existing security implementation, and very
similar to other security APIs out there (JSecurity, Spring Security,
etc). The slight differences are:
Easier to understand and follow. Reading the new permission string
format, you can see what is being checked. Nothing is hidden. The
logic used to determine granular access control it defined on the
permission itself. No more guessing where permission logic is located.
It is much easier to extend, create seed data which overwrites the
default permission logic references and use your own custom logic to
determine access. No need to override service definitions or patch
code (well once the migration is complete) or comment out ECAs.
So, now my questions for you are: What is missing? What does this new
API NOT do, which you are looking for?
Andrew
On May 1, 2009, at 4:37 PM, Adrian Crum wrote:
I read the Auto-Grant section. The question is, where is the seed
data shown in your code example located? If it's it the SFA
component, then the permissions are still spread around. All that
has changed is instead of having permission-modifying SECAs in
components, you have permission-modifying seed data in components.
How was anything "centralized?"
I don't mean to pour cold water on your enthusiasm, it's just that I
don't see where anything is being added or improved. It looks
basically the same, only slightly different.
-Adrian
