Hi Shawn,
Thanks a lot for your detailed answer.
I am in the process of monitoring apache-fortress and currently about
the access part. Based on the architecture of my monitoring system i
should detect and report in-appropriate accesses. For example in an RBAC
situation a role has access only on two certain links and not three.
I think the first tutorial is sufficient in order to do such checks.
My Regards,
Damian
On 7/21/2016 1:28 PM, Shawn McKinney wrote:
On Jul 21, 2016, at 5:08 AM, Damianos Metallidis <[email protected]> wrote:
Can you please tell me which is the main class that does the access checks? I
saw that in the core project we have an AccessMgrConsole,
DelegatedAccessMgrConsole and AdminUtil .
Although i do understand the source code i am not how it work in logic state.
Which of these three classes does fortress use the most?
Damian,
This is the main class where all fortress access checks route through:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/impl/AccessMgrImpl.html
These APIs are invoked in various ways. The AccessMgrConsole is (just) a test
class. It allows one to drive the functions from the command line for testing
and instructional purposes.
There are many other clients of the AccessMgr. For example, the Realm itself
(mostly) uses this class.
To understand how the APIs are used, I’d start here:
https://github.com/apache/directory-fortress-core/blob/master/src/test/java/org/apache/directory/fortress/core/samples/AccessMgrSample.java
To understand how they may be used inside a Web app, check out these tutorials:
1.
http://iamfortress.net/2015/03/13/enabling-java-ee-and-fortress-security-inside-an-apache-wicket-web-app/
2.
http://iamfortress.net/2015/02/16/apache-fortress-end-to-end-security-tutorial/
1 is fairly simple, 2 is more advanced.
The idea here is there are layers of security where different types of checks
are done.
Layer 1 - coarse grained checks. An example of where this can be done is
JavaEE security (where the realm operates)
Layer 2 - medium-grained checks. An example - Spring page level checks
Layer 3 - fine-grained checks. This can be done inside of page components like
buttons.
By itself, none of these layers are sufficient to control security. Each have
advantages and disadvantages. For example Layer 1’s advantage is that is
declarative, meaning programmer unaware. This means unbreakable. It’s weakness is
the control is very coarse. Can you access the app? Layer 2 is also declarative
which is good. It is slightly more granular - i.e. can you view the page? 1 &
2’s weakness is they aren’t fine-grained enough to adequately cover use cases.
Also they use roles as arguments in the access control expression which if not done
judiciously can lead to an explosion of roles, and binds the source code to tightly
to the policy. Layer 3 is fine-grained, uses permission in the access control
expression - which is great, but requires some sort of programmer work to add them
to the app which is a weakness.
Thanks,
Shawn
