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" <[email protected]>
To: [email protected]
Cc: "Anil Patel" <[email protected]>
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" <[email protected]>
> To: [email protected]
> Cc: "Anil Patel" <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>>> From: Andrew Zeneski <[email protected]>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: [email protected]
>>> 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
>>> <[email protected]> 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
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
