--- On Fri, 5/1/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <andrew.zene...@hotwaxmedia.com>
> Subject: Authz API Discussion (was re: svn commit: r770084)
> To: dev@ofbiz.apache.org
> Date: Friday, May 1, 2009, 10:36 AM
> 1. Single point of contact for ALL security checks, instead
> of having security embedded in functionality, or tied to
> services directly, the API should be the governor of all
> security. This means no more writing security logic in the
> functionality, and no more permission services attached
> directly to functionality (services or ecas). This is a bad
> design IMHO because it spreads the permission logic around
> in multiple places and makes it impossible to get the same
> results when checking permissions from different framework
> tools.
I don't understand what this means. Looking at the changes you made in the
Example component, you still have permissions tied to the service definitions.
Then you have permissions being checked in the screen widgets. From my
perspective, nothing changed except the format of the permission string. Where
is the "single point of contact" in the Example component?
> 3. Avoid having to check multiple permissions, for example
> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new
> permission format which embeds all permissions which will be
> accepted:
I don't see that being done explicitly in our current code. The OFBizSecurity
class does that automatically. Any permission check is done with the ADMIN
permission first, then the requested permission.
> 4. Define permission for users, not admins. Instead of
> looking for a static permission, set the permission to be
> checked at the most granular level. When doing so, admin
> users will always have permission and the API will handle
> user access using DA logic.
I disagree. I might want my application to behave differently if an admin is
using it. Without an admin permission (or attribute), how will I know if a user
is in an admin role?
-Adrian
