Use Systems and Stacks

The concepts of Systems and Stacks for DAS Entitlements is conceptually the same as it is for all system types.

System: A DAS Entitlements System represents a real-world software application (or set of applications) that you want to manage Entitlements for.

The following shows a list of Entitlements systems:

1. ACME Employee Portal

2. ACME Partner Management

3. All ACME applications for employees in the US

Stack: A DAS Entitlements Stack represents policies that are enforced across a set of systems. For example, one stack could define the global policies for an organization while another defines the policies that are required for production systems. A stack ensures that when new systems or applications are created, that policy is forcibly applied to all of them; moreover, a stack makes an audit of organization-wide policies especially straightforward.

For example, if every production application in the user environment and therefore every Entitlement System in DAS should reject expired JWTs, then the IAM team (or other administrative user) can add a stack with a policy that denies expired JWTs, and dictate that the stack should be applied to all DAS Entitlements Systems labeled as production. This results in all existing production DAS Entitlement Systems (and all future production DAS Entitlement Systems), that every request with an expired JWT will be denied, even if the application team’s policy allows it.

Multiple stacks: You can choose to have multiple stacks overriding a single system. You can use different teams to put their own policies in place (for example, IAM team, Compliance team, or Auditors, Data Team).

Conflict resolution: Multiple stacks may conflict with each other (and with the systems they apply to). DAS Entitlements resolves conflicts as follows. There are three decisions possible for each stack and system: allow (boolean), deny (boolean), entz (set). The final decision returned to the caller contains two fields:

• allowed: A Boolean indicating whether the request is allowed or not.

  • If any Stack or System denies the request, the request is denied.

  • If none denies, if any Stack or System allows the request, the request is allowed.

  • If none allow nor deny, the request is denied.

  • Moreover, if there are conflicts within a single Stack or System, this same logic is applied.

• ent: entz is the union of all the entz sets across all stacks and systems.

For more information on the response format for decisions, see the Responses.

Decision explanations: Because one or more stack policies may override the decision made by a single system, when debugging policy it is valuable to understand which stack or system actually contributed to the decision. For more information on how to use the Decision Replay Mode to help understand why a decision was made the way it was, see the Responses page.

Stacks vs. Library: A DAS Library also has a collection of Rego code that occurs frequently to reuse them. However, unlike a stack, nothing in the library overrides the policies in a system or stack.

Configure Systems and Stacks

Entitlements Stacks work the same as every other DAS Stack. Every stack has a selector section, where the stack author configures which systems this stack applies to. Each system has labels, as shown in Figure 1.

Figure 1 - System Labels

Each stack selector dictates which combination of system labels are required for this stack to apply.

Figure 2 - Stack Selector

Configure Stack Exceptions

Stack rules can make exceptions for a specific system or number of systems through the system’s features.rego. This policy allows you to define rich data that a stack can use in its rule implementation.

The following shows an example of how a stack defines a rule that denies alice@styra.com as the subject.

enforce[decision] {
    input.subject == "alice@styra.com"
    data.global.systemtypes["entitlements:0.1"].library.policy.general.v1.match_requests[message]

    decision := {
        "denied": true,
        "entz": set(),
        "message": message
    }
}

In a system, any rule that tries to allow alice@styra.com as the subject is denied because its stack rule has higher priority than any of its system rules. In some cases, the system owner may want to make an exception to allow alice@styra.com in their system. The stack owner is required to make changes in the system's feature.rego and the stack rule.

The following shows an example of how an exception definition is added by the stack owner in the system features.rego:

exceptions := {"allow.alice@styra.com"}

To use the definition of the feature exception in a stack rule, look up a system's feature by using data.self.metadata.system_id and skip the rule evaluation by checking for allow.alice@styra.com in features.exceptions:

features := data.metadata[data.self.metadata.system_id].features

enforce[decision] {
    not features.exceptions["allow.alice@styra.com"]

    # same existing rego 
    input.subject == "alice@styra.com"
    data.global.systemtypes["entitlements:0.1"].library.policy.general.v1.match_requests[message]

    decision := {
        "denied": true,
        "entz": set(),
        "message": message
    }
}