In the design I'm working on, the artifacts query an "authorization
manager" - so that the details of permissions management are kept in a
different location. When an artifact is used, it supplies the
authorization manager with the artifact's unique ID and the user's
UserLogin GenericValue, and the authorization manager returns a list of
permissions granted to the user for that artifact.
Like you said, the permissions are not kept in the artifacts themselves.
Having a separate authorization manager not only relieves the artifacts
of permission management details, but the manager itself could delegate
those details to a third party (a network OS or a security policy manager).
-Adrian
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" <adri...@hlmksw.com>
To: dev@ofbiz.apache.org
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