The benefits of the inheritable permissions approach are not a new
concept to me. Keep in mind I was the first person to suggest it.
In the absence of a complete framework rewrite, do you think this
approach would work?
-Adrian
On 11/23/2011 6:19 PM, David E Jones wrote:
Adrian,
It sounds like you're starting to get the point of the run-time
inheritable permission approach that I was trying to introduce into the
project a while back. The general idea being the permission inheritance
is based on screens/services/etc calling other artifacts, ie you keep
track of a stack of artifacts and permissions at run-time, as opposed to
doing it somehow based on inheritance based on location, or even worse
explicit permission checking in services and screens.
BTW, this is already implemented in Moqui.
-David
Adrian Crum wrote:
I am running into that familiar problem of handling authorization in
nested services. Example:
Application A
Invoke Service "A"
Authorized with permissions "A"
Invokes Service "C" in Application "C"
Authorized with permissions "C"
In order for a user to run Service "A", I have to give them permission
to run Service "A" and Service "C". This might not be desirable because
granting permission "C" to the user could give them access to other
things I didn't intend to give them access to.
So far, we have handled that permission issue with permission service
SECAs - where a second permission service is invoked if the first one
fails. SECA Example:
Invoke permission service for permissions "C"
If permission service fails, invoke permission service for permissions
"A"
Return results of permission service "A"
Else
Return results of permission service "C"
This solves the problem (an example can be found in the Asset Maint
application), but it is cumbersome to implement.
There are other places in the project where the problem is solved by
invoking Service "C" with "system" or "admin" user credentials - which
looks hackish to me.
It seems to me this could be made a lot simpler by having the service
dispatcher keep track of previous authorizations. In other words, move
the authorization tracking (which is currently handled outside the
service dispatcher) into the service dispatcher. Example:
Service invoked
If user previously authorized
Execute service
Else
Execute permission service
If user authorized
Set previously authorized to true
Execute service
Set previously authorized to false
With this change, giving the user permission to run Service "A" will
automatically authorize them to run any services called by the service.
Naturally, this approach does not solve the problem if permission checks
are embedded in service code - it depends on the use of permission
services.
So, what do you think?
-Adrian
