On May 5, 2009, at 2:11 PM, Andrew Zeneski wrote:
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.
I'm not sure what you mean by this... which proposal are you referring
to?
If it is the main one you documented and implemented I think there are
some big differences here, mainly that the artifacts themselves do not
have anything in them for configuring access control (permissions,
etc), not even specifying a "process" that they are part of, and
instead the external stuff where access control is configured refers
to the artifacts.
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.
Screens and forms are very much business level artifacts in my
opinion, and it does seem like for the most part when people ask about
configuring access control they have specific screens, forms, form
fields, etc in mind.
As for a process... what is that anyway (I mean on a conceptual level,
putting it in terms that should be understandable by someone not
familiar with what you're working on, and not even familiar with
OFBiz)? Is it a way of grouping screens or other artifacts? If so,
that's fine, in fact that's great, and it's one of many ways of
grouping artifacts to help deal with the fact that at that level of
granularity there are a lot of options to deal with (people usually
ask for it before realizing how many options there really are).
Anyway, to explore the "process" concept further in general a single
artifact (such as a screen) is typically used in more than one
business process. All that means is that a single artifact can be a
member of more than one artifact group and if the user has access to
any of those artifact groups they have access to that screen.
On the other hand, if that is too liberal (which it seems to me, ie it
might allow access where it isn't intended) then we may need to
restrict it more. What I mean by that is the term "process" to me
might mean that they can use a certain screen (or other artifact) as
part of that process, but not as part of any other process or for any
other reason. If that's the case then we need something else in the
project to keep track of which "process" the user is currently in...
and that would be kind of like the Seam "conversation" scope.
Anyway, I don't know if you intended to go to that extend and I think
that considering a "process" as another type of artifact group would
handle what you're thinking of, but I'm really not sure.
On a side note, related to the "Brainstorming: Security Requirements/
Scenarios" thread discussion we had, I haven't heard back from you
about additional statements to add to the list. I think that relates
to this discussion though, so I'm mentioning it just case something
relevant needs to be added there.
-David
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
