You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2011/11/23 09:14:20 UTC
Discussion: Handling Security In Nested Services
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
Re: Discussion: Handling Security In Nested Services
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Discussion: Handling Security In Nested Services
Posted by Nicolas Malin <ma...@librenberry.net>.
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 : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Discussion: Handling Security In Nested Services
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>>>
>>>
>>>
>
>
Re: Discussion: Handling Security In Nested Services
Posted by David E Jones <de...@me.com>.
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
>>>>
>>>
>>>
>
>
Re: Discussion: Handling Security In Nested Services
Posted by Nicolas Malin <ma...@librenberry.net>.
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 : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Discussion: Handling Security In Nested Services
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>
>
>
Re: Discussion: Handling Security In Nested Services
Posted by Nicolas Malin <ma...@librenberry.net>.
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 : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Discussion: Handling Security In Nested Services
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ad...@sandglass-software.com>
> 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" <bi...@gmail.com>
>>> 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
>>> <ad...@sandglass-software.com> 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
>>>>
>>>>
>>>
Re: Discussion: Handling Security In Nested Services
Posted by Adrian Crum <ad...@sandglass-software.com>.
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" <bi...@gmail.com>
>> 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
>> <ad...@sandglass-software.com> 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
>>>
>>>
>>
Re: Discussion: Handling Security In Nested Services
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <bi...@gmail.com>
> 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
> <ad...@sandglass-software.com> 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
>>
>>
>
Re: Discussion: Handling Security In Nested Services
Posted by Bilgin Ibryam <bi...@gmail.com>.
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
<ad...@sandglass-software.com> 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
>
>
Re: Discussion: Handling Security In Nested Services
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>
Re: Discussion: Handling Security In Nested Services
Posted by David E Jones <de...@me.com>.
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
>