We have lot's of fine grained small services with permission service SECAs and the current permission checks doubles its execution time because each service call requires a permission service call.
With the changes you propose I believe there will be significant performance improvement. + 1 Bilgin On Wed, Nov 23, 2011 at 8:14 AM, Adrian Crum <[email protected]> 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 > >
