--- On Sun, 5/3/09, Andrew Zeneski <[email protected]> wrote:
> What you are describing here is very similar to the
> process-based authorization system which I proposed, the
> main differences is in my proposal everything is defined in
> a process [permission] string where this is based on
> artifacts. I think I need to understand this more, as I
> don't really see yet how it would work.
>
> You mention there is no permission-checking code, but you
> also mention that if the user has a specific permission then
> the screen is displayed. This is the confusing part to me
> right now. How does the "domain" know if a user
> has permission if there is no permission checking code?
I could have been more detailed in my description, so I apologize for the
confusion. As far as implementation details are concerned, I intentionally left
those out. The idea is to come up with a design for security first. Once that
design is finalized, we can start working on implementation.
The security domain is just a representation of how OFBiz artifacts are laid
out. It's like a picture of a car. You can't drive the picture, but you can
drive the car.
Each artifact registers itself in the domain. I gave an example using a
<security> element. Following the picture analogy, each <security> element adds
something to the picture.
When a user attempts to access the artifact, the artifact takes its location in
the security domain, and the user login (or whatever) and passes that
information to an authentication mechanism. The authentication mechanism
returns a set of permissions (create, update, delete, view, etc). The artifact
takes those permissions and uses them accordingly (display a screen or return a
permission error, display form data as text, or display form data as input
fields).
To continue with the picture analogy, when the user enters the picture there
will be artifacts there he/she can interact with. Let's say the picture
includes a car, a boat, and lawn mower. The user's ability to start the engine
on the car, boat, or lawn mower depends upon their "start engine" permission
for each. In other words, the car says to the authentication mechanism, "I am a
car. Give me the car permissions for user Adrian." The authentication mechanism
returns a list of permissions. If one of those permissions is "start engine" I
am able to start the car.
> Display a list of example records, for the records the user
> can update display the update button, for the records the
> user can delete show the delete button. For the records
> which the user does not have these permissions don't
> display the button.
Entities are no different than any other OFBiz artifact - they register
themselves in the security domain. Entities could extend the <security> element
with additional elements and attributes that define user permission on each
record.
> When delete is pressed, we need to make sure the user
> really does have access to delete this record, how can we
> verify this?
The Delete button would know to appear only when the user has delete
permission. If the permission doesn't exist, then the button doesn't appear.
> My followup question will be, how do I customize the access
> logic for a specific client so that I can maintain my own
> logic in a private component and avoid problems when
> updating applications?
Why would you want to do that? I can't think of a reason why a security system
would need to be changed.
> For me these are the most important requirements (very
> granular control and ease of customizing without modifying
> files in the application).
I'm confident it will meet most security needs. The concept is not mine - it's
modeled after Novell Netware's security (probably Windows too). I have yet to
find a limitation in the ability to control user access to network resources.
-Adrian
