Part 1

Writing your first policy

In this part, you will create a policy that only allows employees, not contractors, access to the purchase order system.

• All policies and policy sets must reside inside a namespace. Namespaces are used to group related items and prevent name conflicts. Create a namespace in the editor, called AcmeCorp.Finance.

namespace AcmeCorp.Finance
{

}

• You will now create a policy that will secure all requests against purchase orders. At a minimum, a policy has a name and a combining algorithm. Create a policy called PurchaseOrders and use a combining algorithm of permitUnlessDeny.

namespace AcmeCorp.Finance
{
    policy PurchaseOrders
    {
        apply permitUnlessDeny
    }
}

• At present, the PurchaseOrders policy:
  • Is not constrained to purchase order requests
  • Has no rules
• Run this policy via the Run button, and you will receive an outcome in the Output window below of Permit.
• The policy outcome, in this case, is defined by the combining algorithm. Change the combining algorithm to denyUnlessPermit. Re-run the policy, and you will receive a deny.
• You will now restrict the evaluation of the PurchaseOrders policy only for purchase order related requests. You will assume that the system initiating the request will set the Oasis.Attributes.ResourceType attribute to a value of PurchaseOrder. Add a target clause to the PurchaseOrders policy that confirms that ResourceType is PurchaseOrder. Set the combining algorithm to permitUnlessDeny.

namespace AcmeCorp.Finance
{
    policy PurchaseOrders
    {
        apply permitUnlessDeny
        target clause Oasis.Attributes.ResourceType == 'PurchaseOrder'
    }
}

• Re-run the policy, and you will get an outcome of Indeterminate; this is because no policy provided neither a permit nor deny.
• Using the 'Add Attributes' area on the right-hand side of the editor window, add a value for the ResourceType attribute set to PurchaseOrder.
• Re-run the policy you will now receive an outcome of permit.
• You will use quite a few attributes in the Oasis.Attributes namespace so to keep using the namespace is cumbersome - but we can remove that requirement by using an import statement.

namespace AcmeCorp.Finance
{
    import Oasis.Attributes

    policy PurchaseOrders
    {
        apply permitUnlessDeny
        target clause ResourceType == 'PurchaseOrder'
    }
}

• Re-run the policy and verify that it continues to work as before.
• You will now add a rule to restrict access to the purchase order system for users who have the employee role. Rules comprise of the following parts:
  • Name
  • Target Clause
  • Outcome permit or deny
  • Condition
• The only part of a rule that is mandatory is its outcome, permit or deny. Rules can be anonymous, but it makes sense to give rules a name for an enhanced debugging experience. Now create a rule called RestrictAccessToEmployees, and set its outcome to deny.

namespace AcmeCorp.Finance
{
    import Oasis.Attributes

    policy PurchaseOrders
    {
        apply permitUnlessDeny
        target clause ResourceType == 'PurchaseOrder'

        rule RestrictAccessToEmployees
        {
            deny
        }
    }
}

• Re-run the policy, and you will receive an outcome of deny.
• You will assume that the system initiating the request will use the Oasis.Attributes.Subject.Role attribute to represent a user's role membership.
• Now update the RestrictAccessToEmployees rule to contain a condition that returns true if the user is not a member of the employee role.

rule RestrictAccessToEmployees
{
    condition not Subject.Role == 'employee'
    deny
}

• Using the 'Add Attributes' area on the right-hand side of the editor window, add a value for the Role attribute set to employee.
• Re-run the policy, and you will obtain a permit outcome.
• Change the role attribute value to contractor, and re-run the policy, and you will receive a deny outcome.
• You have now written a policy that guards access to the purchase order system by only allowing employees access.