Combining Policies
So far, you have used one policy to define all the authorization logic. Purchase orders could just be a small part of an overall finance application that includes payroll, reporting, accounts, etc. Defining policy for each of these logical areas makes for a more maintainable security model.
For example, in the FinanceApplication
policy set below, each part of the application has its own policy. The FinanceApplication
policy set provides the root policy for all authorization decisions. The PDP will execute each policy in turn until it can determine the outcome of the policy set. In this example, the combinator of firstApplicable means it will stop evaluating as soon as a policy results in either permit or deny. That outcome will be the outcome of the FinanceApplication
policy.
policyset FinanceApplication
{
apply firstApplicable
policy PurchaseOrders
policy Payroll
policy Reporting
}
In this part of the tutorial, you will create a new root policy set, and experiment with different combining algorithms.
- Define a new policy set called FinanceApplication inside the AcmeCorp.Finance namespace, with a combining algorithm of firstApplicable, and reference the
PurchaseOrders
policy.
policyset FinanceApplication
{
apply firstApplicable
policy PurchaseOrders
}
- Clear all the attributes from the right-hand side, use the policy selector next to the Run button to select the FinanceApplication policy and hit Run. You will get an Indeterminate result as no rule or policy produced either a permit or deny.
- Change the combining algorithm to ‘denyUnlessPermit’ and re-run. No rule or policy produced a permit, so you will now get a deny.
policyset FinanceApplication
{
apply denyUnlessPermit
policy PurchaseOrders
}
- Add the following attributes and re-run; you will now get permit
- ResourceType : PurchaseOrder
- Action : Create
- Email : bob@acme.com
- Role : manager
- You will now introduce another policy to allow auditors full access to all finance applications overriding any other policies' constraints. Policy sets can contain other policies and policy sets either by reference or inline. Implement a new policy called
AllowAuditorsFullAccess
inside theFinanceApplication
policy set.
policy AllowAuditorsAllAccess
{
apply firstApplicable
target clause EndsWith("@auditors.com", Subject.Email)
rule allow
{
permit
}
}
- Re-run the
FinanceApplication
policy, and verify that a user with an email address that ends with @auditors.com is always permitted.
You have now completed a grounding in ALFA. Next step is to follow the Securing MVC Application tutorial to see how Enforcer applies ALFA to protect .NET applications.