- Can business managers (who should determine how access controls would be implemented) define and modify authorization logics?
- Can we find new IT technicians to manage these legacy systems? Especially when people who developed the system, left the organization
- Can authorization logics be modified without any source code changes in an dynamic way?
- Is authorization system capable for evaluating following rule? “X resource can be accessed by the Users who are from example.com domain and whose age is greater than 21 years old”
- If we are going to implement a new information system with the organization, can we re-use the authorization logics of a legacy system?
- Can achieve find-grant authorization without defining large number of static combinations?
- Is authorization systems capable of answering following questions: “Can a user, BobAlex, transfer X amount from Y current account at 1.00pm?“
The WSO2 Identity Server is a major player in the XACML and open source world. The Identity Server supports XACML 3.0, which is based on Balana XACML implementation. As the source code, distribution and documentation are available for free, it is possible to analyze and understand the architecture behind it. You can find source code from here. This section provides some information regarding the architecture of the XACML engine (or the entitlement engine) of the WSO2 Identity Server.
Advice is a newly introduced feature with XACML 3.0. Advice is similar to obligations and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives. PEPs do not have to comply with advice statements; PEPs can consider or discard the statement. A common scenario is to explain why something was denied: “User bob Alex is denied because he does because Alex does not have a valid email”.
The XACML specification says that any advice returned with a decision can be safely ignored by compliant PEPs. This means that PEPs should work as described in the previous section, regardless of what the PEP does with the advice it may receive. For example, a PEP must allow access if it receives a Permit decision with no obligations, regardless of any advice in the decision.
As an example, let look at a
Target element. In XACML 2.0, we have an
AND relationship between foo1 and foo2 resources and an
OR relationship between bar1 and bar2 actions. However, we cannot create an
OR relationship between a foo1 resource and bar1 action. so we cannot define something such as “Target would be matched when Bob Alex can access the foo resource or do a bar action” by using the
XACML 3.0 has an
AND relationship between “foo” resource and “bar1″ role and an
OR relationship between “bar2″ action. So we cannot define something as “Target would be matched, when Bob Alex can access foo resource and do bar1 action or do bar2 action”.
This is also a new profile which comes with XACML 3.0. This allows you to define policies about who can write policies about what. For example, “Bob “Alex may issue a policy but only about resources in department X”.