Rego Authoring

Instead of using snippets, if you want to write your own rules then click to the Code view in the policy editor to write custom Rego. The following is an example policy package with one enforce rule and one monitor rule. The first allows alice to write customized rules; the second prohibits bob from writing customized rules.

package policy

enforce[decision] {
    decision := {
        "allowed": true,
        "message": "snippet that allows all requests"
    }
    input.subject == “alice”

}

monitor[decision] {
    decision := {
        "allowed": false,
        "message": "snippet that is not enforced, only monitored"
    }
    input.subject == “bob”
}

Each set enforce and monitor must contain decision objects, each of which is a JSON object. The following fields are permitted in decision objects: allowed, denied, entz, and message.

• allowed and denied fields are mutually exclusive, so only one may be set at a time, and one of these fields is required to be present in the decision object.

• entz is optional and does not affect the allowed outcome. The entz field must be a Rego set and the entz sets from all enforce rules are unioned together and returned in the final outcome. The entz set is intended to be used when clients need more information than a single allowed boolean value. For example, it can be used to return a set of Entitlements that the client should be granted.

• message is optional and does not affect the allowed outcome either. The message field is for informational purposes only. It contains an explanation of why a request was allowed or denied for troubleshooting purposes.

note

The overall policy decision returned to the caller is a combination of the results produced by the DAS system and the collection of DAS stacks that apply to that system. For more information on how those decisions get combined, see Use Systems and Stacks page.