Download your copy of our State of Authorization: Playbook Edition Get it now »

How can I manage many complex permit rules for the same ALFA policy?

See how you can efficiently create and manage complex rules within an ALFA policy that is easy for humans to read and maintain.

ALFA, the abbreviated language for authorization, is an easy-to-write authorization language that uses a lightweight syntax and implements attribute-based access control (ABAC). ALFA uses attributes (key-value pairs) inside policies to convey authorization statements.

We won’t get into every aspect of policy authoring today. For a brief overview of what a policy is, check out the ALFA Language Basics.

Using policy structure and combining algorithms to make a policy easier to read

Have you ever found yourself with a long, complex list of checks that must all be true for a given object and action? Perhaps you have a long list of prerequisite requirements that must be met before granting a user access to a specific resource.

In these cases, all of the conditions must be true for the policy decision point (PDP) to return a Permit decision. You could combine all your checks into a single condition in a single policy but that would be extremely hard to read.

One of the key benefits of using ALFA over flat list languages such as Cedar (a Cedar policy is just a long list of rules that either permitting or restricting rules) or wholly unstructured languages such as Rego is that it comes with a hierarchical policy structure.

Along with the use of combining algorithms (see ALFA Language Basics), this added structure can help organize individual rules in an easy-to-manage-and-read policy. This structure also accelerates policy evaluation compared with a flat list making an ALFA-based PDP blazingly fast.

Let’s consider the following example to help illustrate the concept:

For an attorney to view a court reporter’s transcripts, all of the following must be true:

  1. The attorney must be assigned to the case the transcripts are for.
  2. The attorney must currently be practicing and in good standing with the bar.
  3. The attorney must be licensed to practice in the court in which the case was heard.
  4. The transcripts need to be paid for.

The policy that has all of these requirements broken down into an easy-to-read structure would look like the example below. For the sake of simplicity, the necessary targets and conditions are not shown. It is the structure that is key.

namespace example {
    policyset attorneyViewCourtReporterTranscripts{
        apply denyOverrides
        policy attorneyAssignedToCase{
              apply denyUnlessPermit
              rule attorneyAssignedToCase{
                    permit
              }
        }
        policy practicingAttorneyInGoodStanding{
              apply denyUnlessPermit
              rule practicingAttorneyInGoodStanding{
                    permit
              }
        }
        policy licensedToPracticeInCourtTranscriptWasCreatedIn{
              apply denyUnlessPermit
              rule licensedToPracticeInCourtTranscriptWasCreatedIn{
                    permit
              }
        }
        policy checkCleared{
               apply denyUnlessPermit
               rule checkCleared{
                     permit
               }
        }
    }
}

 

In the above example, all of the rules must be true for an attorney to view the transcript for a case. If any one of these rules is not true, then the “denyUnlessPermit” combining algorithm of the policy object will return “deny” and the “denyOverrides” on the “attorneyViewCourtReporterTranscripts” policy set will override any of the rules that returned “permit.” It’s the use of the combining algorithms that ties this structure together.

Learn more on combining algorithms can be found here.

Graphically, this policy would look like:

AFLA policy permissions flow sample - Axiomatics

Conclusion

If you find yourself needing to put many targets and conditions into one rule where all must be true to return a permit decision, you don’t have to put them all in the same rule. By adding policy structure and breaking the requirements out into their own individual rules, the policy is much easier for us humans to read and for changes to be made if necessary.

Have 30 minutes? Let's show you a demo!

See how our award-winning solution can help you meet today's access control and Zero Trust needs.

Request a demo

  Join us on LinkedIn for more insights
Archived under:
About the author

Mark Berg is Principal Architect on the Axiomatics Engineering team, with a wealth of experience in software post sales implementations, pre-sales, customer care, problem solving and providing technical solutions to businesses.