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"
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 servic
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
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.javacodege
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
Bilg
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 a
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 especi
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 wo
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 imp
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.
O
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
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
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
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 t
14 matches
Mail list logo