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.
This weeks pattern is the Specification Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more in-depth definition you can see here and Here are some useful descriptions, but to appreciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the Specification pattern: “ to separate the logic for (e.g.) filtering an entity from the entity itself.”
Example application for this pattern has been to support filtering as a pluggable entity “collection” of specifications. The implementation details as things mature are apparent with generics and expression tree’s and event the IQueryable<> interfaces against OR/M layers.
The main benefits of this pattern are
1 – Loose coupling of the filter logic from the objects being filtered,
2- Single responsibility: Filtering is essentially a first class citizen and also can exist in a decoupled state for better testing and independent improvement
3 – Composition of specifications allows for reuse and complex nested specifications for easier maintenance.
This weeks pattern is the Memento Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more in-depth definition you can see here and here are some useful descriptions, but to appreciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the Memento pattern: “Without violating encapsulation, capture and externalize an object’s internal state so that the object can be returned to this state later. A Magic cookie encapsulating check point capability, promote undo or rollback to full object status.”
Example application for this pattern has been to support undo or rollback, other common implementations are a finite state machine. In my own personal development projects I have used memento pattern to create and audit trail with full play-back of the payloads as an encapsulation exercise.
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.
This weeks pattern is the FlyWeight Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more indepth definition you can seeandare some usful descriptions, but to appriciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the flyweight pattern: “The intent of this pattern is to use sharing to support a large number of objects that have part of their internal state in common where the other part of state can vary.”
Example application for this pattern has been a text editor abstracting out the state of each character as glyphs. This is a nice concept but really limits the true application for this pattern across the board. When I see this pattern I think caching and this is also very similar to a connection pooling type of resource manager. I think the big difference here is these share some state while other parts are unique making each type a potential hybrid. This week in exploring this pattern think about applications for it. What interesting applications can you think of for this pattern, it seems with the advent of large memory and fast processors this hasn’t been considered except in memory condious applications with limited resources.
This is one of my favorite books because it explains so clearly the process and intention for building or constructing things that live and things that matter. It is a way to express the hidden quality that lies in all natural living things, including buildings, cities, and towns. The principals also apply to building software there is a sense of creation that takes place when building a software system, the larger and more useful the better, this however mirrors the reality that big and complex doesn’t mean better but also that things that scale have an intrinsic beauty of repeatability and patterns. This book is the foundation of Pattern based thought that software design patters were inspired by and that underpin the value of patterns in general.
The best part of this book I think is Chapter 2 : The Quality without a Name. This essentially expresses the inner energy that is life and how you cannot give it a name as this would diminish it. One of the best architecture books available and I will later dive into more detail about how I have personally and professionally used the advice and ideas of this book in practice.