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 >
