Shared conditions

[andrewclymer]

Repeating the same boolean logic throughout a policy is not only tedious but, from a maintenance perspective, does not scale.

From a runtime perspective, it would be great not to repeat the execution of the same condition across policy decisions.

Consider the following ALFA

policy doorAccess {
        target clause ResourceType == "door" and Action == "open"
        apply denyUnlessPermit

        // Employees can open the door during office hours only
        rule mainDoor {
            target clause Resource == "mainDoor"
            permit
            condition Subject.Role == 'employee' and
                      CurrentTime >= "08:00:00":time and
                      CurrentTime < "18:00:00":time
        }
    }

The use of office opening hours could be part of a shared condition.

condition IsOfficeOpen  CurrentTime >= "08:00:00":time &&   CurrentTime < "18:00:00":time

policy doorAccess {
        target clause ResourceType == "door" && Action == "open"
        apply denyUnlessPermit

        // Employees can open the door during office hours only
        rule mainDoor {
            target clause Resource == "mainDoor"
            permit
            condition Subject.Role == 'employee' and IsOfficeOpen
        }
    }

Using shared conditions allows the runtime to cache the result of a shared condition. Reducing the execution overhead.

Some ALFA conditions can look complex, especially when multiple functions are called. The use of shared conditions increases the readability of ALFA and allows a clean separation between developers and policy builders. Developers can create shared conditions, and policy builders can create high-order conditions by combining shared conditions with boolean operators (and, or, not). This results in a form of ALFA that is

• More readable
• Possibility to execute faster when used multiple times in a policy evaluation
• More maintainable

There is an argument to make conditions general-purpose expressions so they can return any result type, not just boolean. Keeping the contract to just boolean expressions creates a level of policy building that does not require deep technical knowledge. If policy conditions were built using shared expressions (return any type), a developer's refactor of the shared expression could break various policies, resulting in an error in the consumer of the shared expression, not in the author of the shared condition. A strong boolean contract prevents this from happening. This is not dissimilar to shared rules, which can only produce a permit or deny.