A Policy in XACML is essentially an XML document that describes a couple of things needed to grant permission or access to a resource. It comes down to some basic composition,
You have a set of three things,
1 – Subject : This is who is requesting access, the “WHO”
2 – Resource: This is the “WHAT” and specifically it is something you are protecting for some reason.
3 – Action: This is the "active verb” that is being performed, usually the activity of what you can do to the resource as in disk-access would be “Read” , “write”, “delete” or could be a function in the system at a higher level “manage” or “review”.
A Policy is linked to these three things which are grouped together as a “target” to make things reusable, and also add shared attributes to the collective.
A Policy also has this thing called “Policy Combining Algorithm” and a “Rule Combining Algorithm” this is the logic to use when more than one policy or rule are in use, the standard default is DENY-OVERRIDES
Deny-Overrides: This is that a deny permission will always override a permit, so that if you have 100 rules applied to you, if only 1 of them is deny, you cannot access, this is a more default-secure method for security.
The Rule is straightforward, it defines the logic and attributes needed to check for security on the target, this is the power of XACML as you can apply a rule which is composed of an Effect and optionally a condition, so this means , effect is always “permit” or “deny” and you can apply a condition optionally to grant the effect based on time of day or other attributes for the user.
Policy Set this is just as it says, a collection of policies which allows for better composition.
Lastly there are these things called “Obligations” which help cross-cut a concern like logging or auditing, preventing rule-explosion.
The composition above describes the Scheme of a Policy and Policy set as is required by the XACML standard. In summary you can see that
A Policy has
0 or 1 Targets,
has 1 policy combining algorithm,
0 or 1 Obligations,
1 Rule Combining Algorithm.
A Target has a Subject, Resource, and Action, and Rule, and a Policy Set and Policy.
A Rule has an Effect and 0 or 1 Conditions, and a Rule Combining Algorithm.
A Policy Set has a Target, A Policy Combining Algorithm, and 0 or 1 Obligations.
An Example Policy is shown below:
Next overview will be around the application of the Policies, and an implementation of a PDP (Policy Decision Point) in C# as an example on how it works internally.
With some of the foundational components defined previously, we will examine the big picture of XACML authentication system and then break out more workflows over time to get an application of this security framework
As you can see in the above diagram. Here is a step-by-step breakdown.
1 – You attempt access to a secure system, you will essentially be calling a PEP (enforcement point) which will check your authentication to ensure you are who you say you are, if you are authentic, it will forward request to PDP.
2- PEP packs this information along with roles and claims to the PDP for a decision to be made about you.
3 – PEP will check cache and return, if not available, it will then try to make a decision, most likely getting information from PIP to make a decision about your authorization access.
4 – PIP will query all identity system usually Active Directory or some Identity system.
5 – PIP will also query any other systems if needed, and send this back to PDP for decision.
6 – PDP caches data from PIP and makes a decision about authorization.
7 – PDP sends decision back to PEP to then allow request or deny.
8 – PEP allows or disallows request based on policies.
We will examine the components and possibly implementation solutions to these problems, and why they are very useful for externalizing security decisions from an application. Another alternate flow is that the PEP controls the data flow as well, rather than just a security check, but would constrain the data based on policies.
RBAC is using permissions and roles to authorize people for access to a system, or parts of a system. It is very straightforward and is standard security used in many different technologies. The basic components for RBAC security is you have subjects, permissions, roles, and operations.
1 – Subjects. A Subject is the person or system that is requesting authorization to perform an operation. In some advanced scenarios the subject would have a context with some session information useful for authorization decisions.
2 – Permissions – A Permission is a granular activity that is well defined, an example would be access to a file-system, permissions would be read-access, or write-access, etc. A permission is made up of smaller components being an operation and a target/resource. This linkage between an operation and a resource with a name/context is the permission.
3- Operation – this is the activity being requested and is linked to a resource where the activity will be completed.
4 – Role – This is the collection of permissions with some description around the purpose and role of the system.
One of the hard requirements for RBAC to work is that you must only assign subjects to roles, and nothing else, as this would bypass the purpose of RBAC as being able to manage and secure things easier. Some of the common problems with RBAC are listed below.
1 – Role Explosion – This is basically that when you have more complicated security requirements you basically need to create a role for every user, or have an exponential role requirement when you are trying to enforce logical security needs having to centralize the roles. RBAC has a notion of a role-hierarchy, where you can nest roles within roles, for permissions, this works well but only considers one scenario.
2 – Role Management – This is where management of roles and subjects is really brittle and cannot easily be fixed, as having roles containing roles and permissions, the biggest problem is knowing the final result, which can be very confusing with role scopes and precedence, the kinds of problems RBAC should solve.
3 – Tightly Coupled – When you have a security system tightly coupled to the other systems, usually RBAC is baked inside the systems it is not designed in an open and modular fashion making expanding and extending impossible.
We will go into more detail on advanced RBAC scenarios, solutions and other systems that will solve your problems.
XACML is a security standard that was created to make the use of security for software easy to configure, extend, and change with minimal impact. It is a policy based language so that you abstract out the security policies from the source code of the systems, making this less tightly coupled. Here is a good overview with more details:
The sad fact is that in development and design of software systems and application security is often an after-thought. most systems leverage an role-based access control (RBAC) system which uses permissions and roles to control access. When or if security policies change things usually require making more roles, and permissions, and management can be difficult. With RBAC you can be plagued with Role-explosion where you need a role for each person to permission mapping especially in context based security requirements.
XACML is a standard defined by the OASIS standards association. XACML is attribute based over role based so that it makes management easier (access based on attributes) but the most important factor is the decoupling of the authorization access from the system so changes are easier and maintenance is also easier. A side-effect of abstracted authorization is that you can interoperate and centralize security to share it across different systems, even federated security scenarios leverage XACML.
The basic design of a XACML systems has 4 main components a PAP, PEP, PIP and PDP
1 – PAP is the Policy Administration Point This is where you administer the policies changing the security rules, and policies. This is separate from the rest of the system as this is decoupled..
2 – PEP is the Policy Enforcement Point. The PEP enforces the access so this is the module that authenticates the request for validity, getting identity information and can also constrain data, cache, and gets the request and then also returns the result, usually a simple Yes or No, however in some systems the actual deliverable, the data being secured is returned from the PEP rather than just a yes/no decision.
3 – PIP is the Policy Information Point. PIP is a service that collects information for the policy decision point to use to make a decision, this is to ensure that all the information that is needed is available. The PIP usually is a front-end to many other backend systems containing the attributes you use for security policies decisions.
4 – PDP is the Policy Decision Point. This is where the magic happens, using a rules engine or something similar, the decision point makes a decision about the access request, and also can loop back to the PIP for more information as the policies are executed.
The diagram shows a basic flow for access to security using a XACML based system.
We will go over some of the more advanced scenarios supported and also the benefits such a system provides even if it may seem like overkill. I think that as systems and information architecture mature this security model will be the future because of the abstraction it allows.