What might be helpful for this is the allow, deny, always-allow pattern. Normally you'd just give users an inheritable "allow" permission, but if the code called/used anything with a "deny" permission associated with it, the user would be denied in spite of the inheritable allow permission.
For admin/special users you'd get around this by using the always-allow permission which ignores deny settings. -David Nicolas Malin wrote: > Le 23/11/2011 22:19, Adrian Crum a écrit : >> Why would you need to force another permission check? > As example : To sure that a other application will not call a service > with admin permission by a service with only update permission. Normally > this situation will not existed, but if it's really important that we > use admin permission prefer force the authorization check instead of a > risk to create a security break. > > Maybe I am little paranoid, > but in my age is difficult to change ;) > > Nicolas >> >> -Adrian >> >> On 11/23/2011 8:54 PM, Nicolas Malin wrote: >>> Hi adrian, >>> >>> If a explain in my words, (if I really understand you solution) : >>> On your first service, you declare permissions and force the inherit >>> authorization on sub services called. >>> >>> On many case, your solution works fine, but for some service, I will >>> keep the possibility to force permission analyze. Exclude this last >>> point, I agree with you. >>> >>> Nicolas >>> >>> Le 23/11/2011 09:14, Adrian Crum a écrit : >>>> 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 >>>> >>> >>> > >
