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" <[email protected]>
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" <[email protected]>
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
<[email protected]> 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
