Discussion: Handling Security In Nested Services

[Adrian Crum-3]

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

[David E. Jones-2]

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
>

[Adrian Crum-3]

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
>>

[Malin Nicolas]

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
>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

Why would you need to force another permission check?

-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
>>
>
>

[Malin Nicolas]

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
>>>
>>
>>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

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
>>>>
>>>
>>>
>
>

[Malin Nicolas]

Le 23/11/2011 22:50, Adrian Crum a écrit :
> 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.

completely agree, and it's not always a good thing.
I especially want to point the fact of not make this process even easier
and be able to safeguard

Nicolas

>
> -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
>>>>>
>>>>
>>>>
>>
>>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

I hope you understand that any mechanism in the inherited permissions
scheme that enforces a permission check on a called service can still be
circumvented by passing the "system" or "admin" userLogin. The
additional check will be pointless.

-Adrian

On 11/23/2011 9:59 PM, Nicolas Malin wrote:

> Le 23/11/2011 22:50, Adrian Crum a écrit :
>> 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.
>
> completely agree, and it's not always a good thing.
> I especially want to point the fact of not make this process even
> easier and be able to safeguard
>
> Nicolas
>
>>
>> -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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[David E. Jones-2]

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
>>>>
>>>
>>>
>
>

[Bilgin Ibryam-2]

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
<[hidden email]> 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
>
>

[Jacques Le Roux]

I know this thread is not about tools but concepts, and I have no digged into details.
However I wonder if using another tool could not help the concept. Of course, I think about Apache Shiro
http://shiro.apache.org/authorization-features.html

Small and easy tutorial/demo http://www.javacodegeeks.com/2011/10/apache-shiro-application-security-made.html

By and large http://shiro.apache.org/index.html

Like we hope to delegate a part of CMS to JackRabbit, delegating Authorisation and Permission to Shiro could maybe facilitate our
work in this area...

Jacques

From: "Bilgin Ibryam" <[hidden email]>

> 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
> <[hidden email]> 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
>>
>>
>

[Adrian Crum-3]

You mentioned it before and I suggested it could be used as the
authorization manager in the security redesign.

Right now I would just like to make invoking services from within
services more convenient without having to rewrite the entire framework.

-Adrian

On 11/27/2011 7:27 PM, Jacques Le Roux wrote:

> I know this thread is not about tools but concepts, and I have no
> digged into details.
> However I wonder if using another tool could not help the concept. Of
> course, I think about Apache Shiro
> http://shiro.apache.org/authorization-features.html
>
> Small and easy tutorial/demo
> http://www.javacodegeeks.com/2011/10/apache-shiro-application-security-made.html
>
> By and large http://shiro.apache.org/index.html
>
> Like we hope to delegate a part of CMS to JackRabbit, delegating
> Authorisation and Permission to Shiro could maybe facilitate our work
> in this area...
>
> Jacques
>
> From: "Bilgin Ibryam" <[hidden email]>
>> 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
>> <[hidden email]> 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
>>>
>>>
>>

[Jacques Le Roux]

Yes, I must say I can't help much at the moment.
I believe you are heading in the right direction...

Jacques

From: "Adrian Crum" <[hidden email]>

> You mentioned it before and I suggested it could be used as the
> authorization manager in the security redesign.
>
> Right now I would just like to make invoking services from within
> services more convenient without having to rewrite the entire framework.
>
> -Adrian
>
> On 11/27/2011 7:27 PM, Jacques Le Roux wrote:
>> I know this thread is not about tools but concepts, and I have no
>> digged into details.
>> However I wonder if using another tool could not help the concept. Of
>> course, I think about Apache Shiro
>> http://shiro.apache.org/authorization-features.html
>>
>> Small and easy tutorial/demo
>> http://www.javacodegeeks.com/2011/10/apache-shiro-application-security-made.html
>>
>> By and large http://shiro.apache.org/index.html
>>
>> Like we hope to delegate a part of CMS to JackRabbit, delegating
>> Authorisation and Permission to Shiro could maybe facilitate our work
>> in this area...
>>
>> Jacques
>>
>> From: "Bilgin Ibryam" <[hidden email]>
>>> 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
>>> <[hidden email]> 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
>>>>
>>>>
>>>