As I mentioned in my original post, this scenario already exists by
passing the "system" or "admin" userLogin to the called service. So,
that potential already exists and is being exploited.
-Adrian
On 11/23/2011 9:46 PM, 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
