On May 1, 2009, at 4:23 PM, Adrian Crum wrote:
--- 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?
What changed is that now the permission logic is NOT tied directly to
the service itself. The logic is tied to the permission. So ANY call
to authz.hasPermission() the EXACT same code runs that checks the
permission. That is the single point of contact, the hasPermission()
method.
The checks in the screen definition runs the same code as the checks
in service definition. So now one advantage is, the update or delete
button which is displayed in the UI if the user has permission will
display (even if they do not have the static permission associated
with their account) if the user can edit that specific item. It won't
display for other items which the user cannot modify.
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.
Okay, so that was a bad example. How about CATALOG_UPDATE or
CATALOG_ROLE_UPDATE instead as an example. Instead a simple permission
defined as update:catalog:${catalogId} would take care of both of
these. If the user has the static 'update:catalog' permission it would
be granted (like a catalog admin might have), otherwise it would run
the DA logic to determine if the user has permission to update that
specific catalog.
One single permission, can handle most if not all cases when defined
properly.
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?
Then we will create an 'admin' base permission. I didn't see the need
for it, b/c I can't think of anything in which I would say "don't show
this to people who can access/create/read/update/delete; only show it
to an admin". I have nothing against this, just couldn't think of any
really useful cases. Do you have something specific in mind?
Andrew
