Well, this is starting to sound exactly like what I proposed, with the
exception that in my proposal everything would be tied to a "process"
rather than an artifact. The process of "updating a party record" is
attached to the artifacts which are involved in the process, then
permission logic is attached (by database configuration) to that very
same process.
To me a process driven model is far more comprehendible to an average
application administrator, where an artifact based would be way more
technical. An administrator would need to understand all the artifacts
in the application in order to configure things properly. Where in a
process model, the admin only needs to understand the process involved
and the artifacts are associated to the process during development.
Defining the processes involved in an application is something which
should be done during design. During implementation, all that needs to
be addressed is associating the artifacts to the correct process.
In my opinion security should be thought of as a business level
requirement, putting it on the artifact is too technical.
Andrew
On May 5, 2009, at 3:59 PM, David E Jones wrote:
Exactly, I like this direction a lot better too... ie don't have the
permissions in the artifacts but have them all in a separate place
that refers back to the artifacts (and other things) as needed.
With it outside the artifacts and centralized in database driven
configuration, it would be a LOT easier for end-users to have
control and configure things in a wide variety of ways, without
needing a programmer and without changing any XML, Java, groovy or
anything.
-David
On May 5, 2009, at 11:43 AM, Andrew Zeneski wrote:
To me this sounds like the security information is being spread out
in ever more places, not consolidated. If I need to customize the
authorization logic, I would much rather it be centralized and NOT
in the artifacts. If it was in the artifacts, much like it is
today, then customizing would require modifications to the OOTB
artifacts. Which is exactly what we should be avoiding.
Andrew
On May 5, 2009, at 11:42 AM, Adrian Crum wrote:
In the design I proposed, the configuration resides in the
artifacts themselves.
-Adrian
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
