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?
How does is the access control logic handled in this system? Could you
explain how to accomplish this example using this pattern:
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.
When delete is pressed, we need to make sure the user really does have
access to delete this record, how can we verify this?
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?
For me these are the most important requirements (very granular
control and ease of customizing without modifying files in the
application).
Andrew
On May 3, 2009, at 12:57 PM, Adrian Crum wrote:
Take your comment - "it's the artifact we want the code attached to
not the permission itself" - and combine that with Scott's
suggestion to have a security-aware delegator, and you have a
solution I proposed years ago: a domain-driven security system.
In a domain-driven security system, each OFBiz artifact is
responsible for handling security for itself. There is no explicit
permission-checking code. Each OFBiz artifact identifies itself in a
security domain. When a user tries to use that artifact, it checks
the user's permissions against its own position in the domain.
Using the Example component's EditExample screen as an example, here
is what a security domain might look like:
framework
example
screen
EditExample (screen)
EditExample (form)
Permissions are hierarchical - each artifact inherits permissions
from the artifact above it. This is very similar to what Andrew is
trying to achieve, but it's different because the artifacts
themselves control the security - there is no call to a permission
service with a permission string.
Here's what it might look like in ExampleScreens.xml:
<screens xmlns:xsi="...">
<security domain="framework:example:screen"/>
<screen name="EditExample">
<security domain="EditExample"/>
...
</screen>
</screens>
Notice there are no explicit permission checks. Instead, each
artifact has identified itself in the security domain.
When the widget is run, each artifact checks the user's permissions
against its own security domain. So, the EditExample screen would
look for the framework:example:screen:EditExample" permissions and
handle itself accordingly. (Andrew - this is why I suggested having
permission checking code return all permissions for a context.)
If a user has the access:framework:example:screen:EditExample
permission, the screen will display.
Let's take a look at what happens in the form widget. Here is what
ExampleForms would look like:
<form name="EditExample" type="single" target="updateExample"
title="" default-map-name="example">
<security domain="EditExample"/>
...
</form>
Again, when the widget is run, each artifact checks the user's
permissions against its own security domain. So, the EditExample
form would look for the
framework:example:screen:EditExample:EditExample" permissions and
handle itself accordingly.
Let's say the user doesn't have any permissions for that context.
Keep in mind permissions are hierarchical - so the form widget would
work its way up the hierarchy to find permissions. If a user has the
access:framework:example:screen:EditExample permission, the form
will display plain text with no input fields. If the user has the
update:framework:example:screen:EditExample permission, the form
will provide input fields.
Form fields could identify themselves in the security domain as well
- so only the fields the user is permitted to access will appear.
Service definitions and entities could identify themselves in the
security domain in a similar way, and have similar permissions
checking logic. Some examples:
framework
example
service
updateExample
framework
example
entity
Example
The nice thing about this approach is that you could leverage the
artifact gathering code to display the security domain as a tree -
with permission checkboxes next to each "leaf." That would enable
any administrator to manage user security easily.
-Adrian
