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.

Pattern of the week: Specification Pattern

January 19, 2012 by · Leave a Comment
Filed under: Architecture, Design, Patterns 

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.”

Specification_UML

 

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.

Pattern of the week: Memento

January 14, 2012 by · Leave a Comment
Filed under: Architecture, Design, Patterns, Programming 

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.”

 

memento

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. 

Technical Writing: Writing a good functional specification.

January 11, 2012 by · Leave a Comment
Filed under: Business, Design, Uncategorized, Writing 

Documentation… The bane of many developers and architects, who would rather write code or prototypes, maybe even tests or bug fixes.  Documentation has been a topic of great controversy, pitting Agile against Waterfall.  There have been many attempts over the decades to replace technical or functional specifications with Domain Specific Languages (DSLs) that can auto-generate code from a written document.  What is unfortunate is that the value of good documentation is lost in the mix usually because of some common pitfalls.

Pitfall # 1 –The goal and reasoning behind documentation is not clear.

Pitfall # 2 – The value of the documentation is not usually given to those who create it, and ultimately it is usually a lower priority than code and as a process is usually not followed so code and documentation get out of sync.

Pitfall # 3 – Developers have not been training appropriately around good practices, and guidance, these are usually given to analysts and project managers, who don’t know the code or technical capability as well.

Pitfall # 4 – Time…. usually as a lower priority no time is given to documentation and many modern practices (Agile) value readable code over documentation (Thought I would argue a functional specification is similar to a story, but perhaps more technical in business terms.)

Pattern of the week: Flyweight

January 6, 2012 by · Leave a Comment
Filed under: Architecture, Design, Patterns 

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.”

 

Flyweight UML Diagram

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.

Skyline Query

January 4, 2012 by · 1 Comment
Filed under: Design, Programming 

A Skyline query is one of the most useful but least obvious data programming patterns.  When you have a set of data and a query with 2 constraints that are conflicting, the output of this is the “Skyline” Query.  If you want to thing about what skyline means and why it describes this issue take the example of searching for cars to drive, and lets say you want the biggest car with the best gas mileage.  These two constraints are conflicting since as cars get bigger, gas mileage usually goes down, but a skyline query essentially runs this query across a set of data and then grabs the tops of the skylines. This would take a cluster of data and grab the top 2 or 3 in that set, then move along to find the next set, this way you can give the user choices without having to come up with an artificial weight or

 

A more realistic example would be searching for a house that is the cheapest cost, that is the biggest, and say closest to where you work.  This is one of the rare data patterns that has so many real world applications it is not commonly known below we will show an implementation of an efficient algorithm shown in this paper to offer stellar performance.

The Skyline Operator

They showed that the best performance for a multi-dimensional skyline processor is a Block – Nested Loop.

Here is some psudo-code with implementation coming next. I’ll show brute-force then also

an implementation with the block-nested loop for T-SQL..

   1:  M – Input of dimensional points
   2:  R output of dimensional points
   3:  T temporary file for dimensional points
   4:  S set of dimensional points
   5:  p < q point p is dominated by point q
   6:   
   7:  function SkylineBNL(Input)
   8:  {
   9:  Output = 0; 
  10:  Temp = 0; 
  11:  Set=0;
  12:  CountIn = 0;
  13:  CountOut = 0;
  14:   
  15:  while(input)
  16:  do
  17:  {
  18:  foreach p in Set
  19:  {
  20:  if(TimeStamp(p)=countin 
  21:  {
  22:  save(Output, p), Release(p)
  23:  }
  24:  Load(Input,p)
  25:  TimeStamp(p) = CountOut;
  26:  CountIn++
  27:  foreach(q in Set)
  28:  {
  29:  if(p>q) release (p) break;
  30:  if(p<q) then reelase(q);
  31:  }
  32:  if(MemoryAvailable)
  33:  {
  34:  save(Temp,p), release(p)
  35:  CountOut ++;
  36:  }
  37:  //keep it running to iterate through entire sets.
  38:  if(Main == empty)
  39:  {
  40:  Main = Temp;
  41:  Temp=0;CountIn=0;CountOut=0;
  42:  }
  43:  }
  44:  }
  45:   
  46:  //flush
  47:  foreach(p in Set)
  48:  {
  49:  save(Output,p), release(p)
  50:  }
  51:   
  52:  return Output;

The Timeless Way of Building

January 1, 2012 by · Leave a Comment
Filed under: Architecture, Design 

timeless

Amazon Link

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.