XACML: What is a Policy and Policy Set?

January 21, 2012 by · Leave a Comment
Filed under: Design, Security 

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. 

image

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:

image

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.

XACML User Work-Flow

January 20, 2012 by · Leave a Comment
Filed under: Architecture, Security 

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

.xacml workflow

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.

eXtensible Access Control Markup Language (XACML) what is it and why is it important?

January 7, 2012 by · 1 Comment
Filed under: Architecture, Security 

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. 

XACML

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.

WCF 3.5 SP1 allows for circular references without adding any code

April 7, 2009 by · 1 Comment
Filed under: Programming, Software Configuration, WCF 

WCF now provides a way to avoid circular reference problems on serialization, which before required you to initialize the Data Contract Serializer with a KeepReferences setting. Another option was to cheat and use a NetDataContractSerializer which wasn’t easier without cusotm behaviors or special code, now it is as simple as adding an attribute.

 Here is one such exception you may receive if you are having issues:

“Object Graph for Type X Contains Cycles and

Cannot be Serialized if Reference Tracking is Disabled”

 

Example that will work wonders without anything else required.

[DataContract(IsReference = true)]

    public class Person

    {

        [DataMember]

        public string Name

        { get; set; }

       

        [DataMember]

        public string Address

        { get; set; }

 

  [DataMember]

        public List<Person> Children

        { get; set; }

 

    }

Now it works, Another example more appropriate is using eXtensible Access Control Markup Language (XACML)  specification.

[DataContract(IsReference = true)]

    public class PolicySet

    {

        [DataMember]

        public string Name

        { get; set; }

       

 

  [DataMember]

        public List<PolicySet> PolicySets

        { get; set; }

 

  [DataMember]

        public List<PolicySet> ParentPolicySet

        { get; set; }

 

 

    }

[DataContract(IsReference = true)]

    public class Policy

    {

[DataMember]

        public string Name

        { get; set; }

 

        [DataMember]

        public PolicySet ParentPolicySet

        { get; set; }

 

  [DataMember]

        public List<Rule> Rules

        { get; set; }

 

 

    }

[DataContract(IsReference = true)]

    public class Rule

    {

[DataMember]

        public string Name

        { get; set; }

 

        [DataMember]

        public Policy ParentPolicy

        { get; set; }

 

  [DataMember]

        public List<Targets> Targets

       { get; set; }

    }