On May 3, 2009, at 2:43 PM, Anil Patel wrote:
Inline.
On May 3, 2009, at 1:36 PM, David E Jones wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones <david.jo...@hotwaxmedia.com>
wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for the services versus
direct permission part anyway, and we decided long ago that
flexibility was better than ease in this case; and yes there
is a creative way to invoke code attached to permissions,
but that is a bit inflexible IMO since much permission logic
involved multiple permissions... it's the artifact we
want the code attached to not the permission itself)
I've been thinking about that aspect of it. If I understand
correctly, here are two of the issues being addressed by the new
security:
1. Permission checking is being done in scripts, so a programmer
is required to change the permission checking logic. An ordinary
systems administrator with no knowledge of mini-language would not
be able to change how permissions are checked. The new permission
string is supposed to make changes to permission checking easier
for the non-programmer administrators.
I see potential in proposed system. Now we have a logical string
that defines permission requirements. If the string points to entity
then check permission service will do the job. In case string points
to logical entity in system like "sfa:contact" then permission check
service can look in auto-grant data to find dependency.
We can build tools for Administrator to add entity level permission,
e.g "sfa:contact" will have partymgr:party as auto-grant.
2. Permission checking isn't consistent. Two similar branches of
logic will check permissions in two different ways: one will check
a permission string, and another will run a script. This is common
in the UI versus the services called by the UI. A simple "has
permission" check is done in the UI, and then the service invoked
runs a script to check permissions.
I agree with you that substituting the permission service with a
permission string is too inflexible.
I don't agree with inflexible part. Instead existing way of
embedding permission rules in services are too rigid/static. I
cannot query permission check service to find out what kind of
permission is required. The new permission string thing lets me do
that. I can query service model to get information on what kind of
permissions are required to run that service. This allows me to
build tools that makes administrator life lot easy.
The auto-grant extension make it so much flexible because its data
driven.
One of the ideas I've been toying with is the idea of a permission
expression. I started writing some code for that and was going to
put it in Jira, but I decided to put it on the shelf until the
dust settles from this thread.
Let's say we took Andrew's new permission string and gave it more
oomph - where it could contain functions and such. (The expression
language would be simple enough for common administrators to
understand.) That could eliminate many of the permission checking
scripts. In effect, the permission string becomes a mini-script.
This mini-script could be used anywhere a permission string is
being used now.
Do you mean Administrator will exit servicedef file? I think its too
much to expect from them. Also it will require redeployment.
I mean edit.
One of the problems I have with what has been proposed so far is
that the permission string can be ambiguous when it comes to
inserting parameters. For example, "update:example:${exampleId}" -
what does that mean? There's no way to tell by looking at it. It
would be preferable to have something like "update:example +
relatedTo(exampleId)". That permission tells me something - it
requires update:example permission and the user must be related to
exampleId in some way.
I don't see how adding relatedTo adds meaning. Dynamic access thing
comes into play only if we are going to check if user is related to
a particular data.
I think permission expressions would solve both of the issues above.
Part of the point (if I remember right) of putting permission logic
into little services was to help keep it consistent when that
service is called in multiple places, especially in the input
processing service and the output generating screen.
If we have cases where a direct permission check is done on the
screen and a permission service is used for the input processing
service, then we should really change the screen to also call that
same service.
I guess the real trick with all of this is to make any easy way to
do dynamic permissions. So far we have these approaches on the
table (sorry if I missed any others...):
1. the current recommended practice of writing a service to perform
permission logic (service can be implemented in simple-method,
java, groovy, etc; normally the easiest way to write and maintain
(and in the future to create tools to help write and maintain) is a
simple-method XML snippet)
2. Andrew's new pattern of attaching a groovy script to certain
permission strings to override the normal behavior of that string
3. Adrian's idea to create some new expression (possibly extend
what Andrew has done) and add functions to the permission string
itself (which might eventually have boolean logic and other things,
and be a little expression language of its own)
Does that sound about right?
When comparing these the big question for me is what will be
easiest for users to maintain, especially less technical users (ie
non-programmers, or I guess also programmers with little time and
patience)?
In general I don't know if we'll EVER be able to come up with
something that allows non-technical users to easily configure
dynamic permissions to handle any possible situation. On the other
hand, maybe we can create something that handles most common cases
(including both functionality level and simple record level cases)
and leave in extension points so that it is possible to create more
complicated permission logic when needed.
In other words, however we do this we probably want some
configurable permissions that cover most stuff, and then extension
mechanisms to drop-down to lower level tools. That is the pattern
used in pretty much all of the OFBiz framework tools, and it would
be good to apply it here too.
A quick note on the extension mechanism: another pattern that has
emerged over time is to allow programmers to create custom logic
and put it somewhere that less-technical users can refer to. The
reason for this is that the custom stuff becomes a sort of tool
that can be documented and then used (but not manipulated) by less
technical users as part of their configuration. In other words the
pattern would look like the configuration part of things having the
ability to reference the custom logic part of things, and not the
other way around (to make it clear, that's a big distinction
between #1 and #2 above, and I'm not sure about #3 since it seems
to mostly be meant to internalize things in the permission string/
expression instead of referring to external stuff, but could
certainly easily point explicitly to external stuff).
Anyway, THANK YOU Adrian, this message is a breath of fresh air
(part of why I changed the subject line :) ) and it's great to
discuss actual issues and patterns and possible solutions.
-David
