See the following topics for information on XACML and also on the architecture of XACML.
...
- 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?“
...
XACML system architecture
Policy Decision Point (PDP) evaluates policies against access requests provided by Policy Enforcement Points (PEP). To provide the decisions, PDP may also need to query a Policy Information Point (PIP) to gather descriptive attributes about the user or any other missing attribute in the request. Policy Administration Point (PAP) is used to manage the PDP and PIP functionality.
XACML terminology
The XACML reference architecture illustrated above is comprised of the following four 'building blocks'.
...
The XACML engine of the WSO2 Identity Server has two major components, i.e., PAP and PDP. This section focuses on Policy Decision Policy Point (PDP) only.
The following diagram represents the component architecture of the PDP.
...
Advice is a newly introduced feature with XACML 3.0 which is similar to obligations. 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 not have a valid email”.
...
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 Target element.
...
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”.