You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <da...@hotwaxmedia.com> on 2009/05/03 19:36:48 UTC
Easier Dynamic Permissions (was: Authz API Discussion)
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
> --- On Sat, 5/2/09, David E Jones <da...@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.
>
> 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.
>
> 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.
>
> 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 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
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 <da...@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
>>
>
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 <da...@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.
>> 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
>
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by an...@hotwaxmedia.com.
Just for clarification, my proposal did include a new way to write
permissions using groovy, but it also supports permissions as services
ad well as a new interface to implement very common permission
checking routines for re-usability.
This was only one part of the proposal, the main focus is on not
attaching the logic directly to the service instead it is attached to
a verbose permission. The reason for this is to make customization of
the permission logic easy to maintain, and not require modifying the
actual application.
The point is, the groovy part you keep referring to is just a minor
extra and not the focus of the framework.
Andrew
On May 3, 2009, at 1:38 PM, David E Jones
<da...@hotwaxmedia.com> wrote:
>
> On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
>
>>
>> --- On Sat, 5/2/09, David E Jones <da...@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.
>>
>> 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.
>>
>> 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.
>>
>> 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 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
>
Re: Easier Dynamic Permissions
Posted by Adam Heath <do...@brainfood.com>.
Anil Patel wrote:
>> 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.
> How is writing "acctgInvoicePermissionCheck" different from
> "update:acctmgr:invoice". I cannot interpret anything out of
> acctgInvoicePermissionCheck but string does tell me something which goes
> in line with convention over configurations practice.
acctmgr:invoice:update would be better, imho. But I can see it argued
both ways.
Re: Easier Dynamic Permissions (was: Authz API Discussion)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 <da...@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.
>>
>> 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.
>>
>> 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.
>>
>> 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 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.
How is writing "acctgInvoicePermissionCheck" different from
"update:acctmgr:invoice". I cannot interpret anything out of
acctgInvoicePermissionCheck but string does tell me something which
goes in line with convention over configurations practice.
>
>
> 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.
Forms and screens don't always work on data from one entity. I can use
string to check "update:ecommerce:billingAndShippingAddress" and use
auto-grant to power permission check service. If data for auto-grant
is set right we will not have to write any custom code to check
permission for most cases.
>
>
> 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)
>
Too many rules embedded in services is bad. They make administrators
life difficult. I have to find and read permission check service to
figure out what permissions should be given to user.
> 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)?
Something that does not require me to look at code and redeploy
application.
>
>
> 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
>
Re: Easier Dynamic Permissions
Posted by Adam Heath <do...@brainfood.com>.
Don't need to actually respond to any particular thing David said,
just reusing his change of subject for my email.
==
PermissionNameOrPattern Command Action Roles
----------------------- ------- ------ -----
/Path/To/Resource UPDATE ALLOW \
(FOO_ADMIN|FOO_UPDATE)&FOO_TRAINED
/Path/Pattern.* CREATE ALLOW \
(FOO_ADMIN|FOO_CREATE)&FOO_TRAINED
PARTY_MGR READ ALLOW \
PARTY_ADMIN&PARTY_TRAINED
==
We have something similiar to this in our client apps. It hasn't yet
made it to the base webslinger code. It's not any kind of fancy
parser. Just tab separated(for now, that would have to change if the
Name allowed spaces).
The 'framework' is the parser, and the api that can be called by
code($resource.userAllowed($user, $command)). The
Command/Action/Roles are not hard-coded.
Again, I haven't actually read the proposal. The above makes the
application code easy to understand. It's not polluted with
boiler-plate security code; instead, it has a simple string that can
be descriptive of what it is checking. It allows clients to change
the security(based on whatever policy they have), without having to
understand any kind of programming logic.
I'm fairly good with javacc. The above would be *simple* to write a
javacc parser for. I've got a SQL parser sitting in the wings, as is
what I was actually working on this weekend, trying to add it to ofbiz.