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
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
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
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 adrian.c...@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
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
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
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
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
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
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.
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
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
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
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:
14 matches
Mail list logo
