The configuration of permissions/etc would be in the database, but the point is that we don't need (or want) records for each artifact in the database. With the ArtifactInfo stuff we can get all artifact data, and then refer to those by their location and/or name.

During execution the various framework tools only need to see if the artifact they are running has permissions associated with them, and it would look them up by these very things, ie the location and/or name (depending on the artifact).

-David


On May 5, 2009, at 9:21 AM, Harmeet Bedi wrote:

If goal is to change security without changing code or XML configuration.. the configuration has to reside somewhere. db seemed like a spot. UI would needs to show the artifacts and permission and configure groups on them. I had SecurityPermission entity extended to have SecurityResource(Artifact) and SecurityActionType(e.g. access)

If the issue is that should there be no static check and collect resources to seed db, instead to it dynamically it would be fine. It would make things dynamic and configuration friendly while still taking config out of xml.

Harmeet
----- Original Message -----
From: "Adrian Crum" <[email protected]>
To: [email protected]
Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern
Subject: Re: Domain Based Security ( was re: Authz...)

Harmeet Bedi wrote:
Ofbiz has the graph metadata of artifacts but navigating graph to
dynamically determine will be expensive.

It doesn't have to be. If we end up using the artifact info stuff for
some kind of security administration screen, we can set up the artifact gathering code to go only as deep as what is currently being displayed.
In other words, the artifact gathering could be more dynamic. As the
user navigates farther down the graph, additional parsing is done.

This would eliminate the need to graph all artifacts in one step.

I agree with David that storing the graph in the database is a bad idea.

-Adrian

Reply via email to