Security permission seems to be based on action, resource and
context of resource.
I have been working on system to extending ofbiz security for our
custom system.
A main difference is that we wanted to get away from has-permission
constructs in the xml files. Hope was that end users would be able
to create new groups, edit membership, associate resource and action
with a set of groups through UI and manipulating database tables.
The extension we were thinking of is add to SecurityPermission
Resource and Action information
SecurityPermission references SecurityActionType(new)
SecurityPermission references SecurityResource(new)
SecurityResource references SecurityResourceType(new)
<extend-entity entity-name="SecurityPermission">
<field name="resourceId" type="id-ne"></field>
<field name="actionTypeId" type="id-ne"></field>
</extend-entity>
<entity entity-name="SecurityActionType" title="Security Action
Type">
<field name="actionTypeId" type="id-ne"></field>
<field name="parentTypeId" type="id-ne"></field>
<field name="hasTable" type="indicator"></field>
<field name="description" type="description"></field>
</entity>
<entity entity-name="SecurityResource" title="Security Resource">
<field name="resourceId" type="id-ne"></field>
<field name="parentId" type="id-ne"></field>
<field name="resourceTypeId" type="id-long"></field>
<field name="application" type="name"></field>
<field name="resourceName" type="name"></field>
<field name="fullPath" type="long-varchar"></field>
<field name="description" type="description"></field>
</entity>
<entity entity-name="SecurityResourceType" title="Security
Resource Type">
<field name="resourceTypeId" type="id-long"></field>
<field name="parentTypeId" type="id-long"></field>
<field name="hasTable" type="indicator"></field>
<field name="description" type="description"></field>
</entity>
SecurityResourceType is types derived from ModelWidget (screens,
forms, screelets, hyperlink etc.), Entries(Request Map) in
controller.xml, db entities, services etc.
Changed ModelWidget to put in hooks for access control
public abstract class ModelWidget<R extends ModelWidgetRenderer>
implements Serializable {
...
/**
* renders widget. Writes render output to writer.
* Applies access control and calls abstract renderWidget method
if allowed to render
* @param writer target for rendering
* @param context context used by widget to render itself.
* @param renderer renderer specific to derived class
*/
public final void render(final Appendable writer, final
Map<String, Object> context, final R renderer)
throws GeneralException, IOException
{
....
}
/**
* called after acl check is done and widget can be rendered.
Derived classes need to implement this method
*/
protected abstract void renderWidget(Appendable writer,
Map<String, Object> context, R renderer)
throws GeneralException, IOException;
...
}
ModelScreen::renderScreenString changed to ModelScreen::renderWidget
ModelScreen has this:
public class ModelScreen extends ModelWidget<ScreenStringRenderer>
implements Serializable {
..
@Override
protected void renderWidget(Appendable writer, Map<String,
Object> context, ScreenStringRenderer screenStringRenderer)
throws ScreenRenderException { ... }
}
The net result is that to secure access(action type) for a
screen(resource) we can add entry in db for the resource and a
unique permission id for resource and action(intent something like
access:ap:report in doc). Intent is to build this list by statically
examining the xml files(*Screens.xml, controller.xml etc) to build
database seed.
The way we were thinking of configuring was that each resource(page -
> top level screen) has a link to manage access groups based on
logged in users' permission. Clicking on link shows list of groups
and update mechanism to associate security groups with action
+resource using standard SecurityGroupPermission table
This seems to have some overlap with proposals in this thread.
We are based on an older ofbiz fork, but would like to contribute if
there is interest.
Harmeet
----- Original Message -----
From: "Anil Patel" <anil.pa...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
Cc: "Anil Patel" <anil.pa...@hotwaxmedia.com>
Sent: Monday, May 4, 2009 9:19:21 AM GMT -05:00 US/Canada Eastern
Subject: Re: Domain Based Security ( was re: Authz...)
Vince,
Here are the documents
http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor
http://docs.ofbiz.org/display/~jaz/Permissions+By+Application
Thanks for asking for the document. I have example on "How successful
people been in confusing the community".
Regards
Anil Patel
On May 4, 2009, at 9:11 AM, Vince Clark wrote:
Anil, you mentioned a document. Can you send out the link? I'm sure
it is in these threads somewhere but with all the traffic on this
topic I cannot seem to find a link to the doc.
----- Original Message -----
From: "Anil Patel" <anil.pa...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
Cc: "Anil Patel" <anil.pa...@hotwaxmedia.com>
Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
Subject: Re: Domain Based Security ( was re: Authz...)
Over last few days this discussion has changed subject few times.
This
is going more on lines of "confuse them if you cannot convenience".
The new security system proposal document, implementation code and
code demonstrating its use, been out for more then week, All big
names
in community have had chance to see it. I will rather discuss on list
of items that are so bad about new security system (which is now in
proposal status). If Andrew or others who like it cannot solve or
disprove them then either we will know that its bad and cannot be
used.
I like the system and will like to use it.
Regards
Anil Patel
On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
I don't see us agreeing on anything. I'm saying each artifact is
responsible for its own security. You're saying security is defined
by a process.
If you were to view a collection of artifacts - each responsible for
its own security - defining some kind of process-driven security,
then that might be true.
Applying your process-driven security design to the picture analogy
(from what I have gathered so far from your design), it would be
like there is a gatekeeper at the entrance to the picture. The
gatekeeper says "Adrian intends to start the car, does he have
permission to do that?" The car has no say in the matter. The
gatekeeper controls everything.
The inherent limitation to that design is, the gatekeeper has to
account for every motive I might have in interacting with every
artifact in the picture. That gatekeeper has a lot on its hands!
I think it is simpler to have each artifact decide for itself what
Adrian can or cannot do with it. I believe that was what David was
trying to express when he said "it's the artifact we want the code
attached to not the permission itself."
-Adrian
--- On Sun, 5/3/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com>
wrote:
From: Andrew Zeneski <andrew.zene...@hotwaxmedia.com>
Subject: Re: Domain Based Security ( was re: Authz...)
To: dev@ofbiz.apache.org
Date: Sunday, May 3, 2009, 11:00 PM
I like to think of it more as process-driven permission vs
artifact driven permissions, because the "permission
string" is defined to match a specific process. Other
than that I think we finally agreed on something.. Ha! :)
On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
--- On Sun, 5/3/09, Andrew Zeneski
<andrew.zene...@hotwaxmedia.com> wrote:
The question I believe now is, which is better? I
personally think in terms of processes which is
why what I
proposed was all process based. However, artifact
based may
be more granular, but possibly too granular. If I
understand
this right, artifact based we could potentially
have
different access requirements for every single
form/screen/service/entity/etc; where in a process
based
system the developer would define the processes as
part of
the application and these processes could be
shared across
common artifacts (forms can share with screens
that share
with services, etc).
Does this sound like a fair assessment?
Yes it is. It boils down to permission-driven
permissions, versus artifact-driven permissions.
-Adrian
