Skip to main content

Overview of the Styra DAS Entitlements System

The Styra DAS Entitlements System type provides a cloud-native Entitlements service which can be easily integrated into existing applications, replicated globally, and managed and governed through a single pane of glass.

The Styra DAS Entitlements System provides users with a centralized Entitlements management system for their Self-Hosted custom applications. Instead of hard-coding into every software application the rules and regulations about what type of users can perform the actions and when they can perform the actions, developers can instead integrate custom applications with a separate system that handles all of those rules and regulations on behalf of the application.

For more information on how to utilize Entitlements, how to create and validate an Entitlements policy, how to consume data from an external data source, and how to integrate Entitlements with your application, see the Entitlements tutorial.

Features​

Styra DAS for cloud-native Entitlements provides the following key features:

  • Policy management lifecycle: Styra DAS provides policy lifecycle management capabilities, which includes authoring policy, testing, deploying, and monitoring. It is designed specifically to manage OPA and OPA policies throughout the entire lifecycle. Different policy authoring interfaces enable different personas to write policies and help others in the organization write policies.

  • Data management: Data management relies on data that come from one or more systems of record that are often tier 0 (tier zero) services like Lightweight Directory Access Protocol (LDAP) or Active Directory (AD). Synchronizing this data with Styra DAS is required to distribute the relevant data to the OPAs that need it through encrypted channels and keep those OPAs up to date as the systems of record change.

  • Enterprise-grade governance: Often, Entitlements are the responsibility of multiple users throughout the organization. Examples of governance include ensuring there are proper controls over who can change policies, when they can be deployed, what tests must pass, and what impact threshold must be met before release.

  • API driven: Styra DAS is 100% API driven with Styra DAS Self-Hosted or Styra DAS SaaS offering. Styra DAS integrates with existing tools including Git, Prometheus, Kubernetes, S3, Datadog, and Slack.

Benefits​

Styra DAS for cloud-native Entitlements provides the following benefits:

  • Cloud-Native Entitlement Service: An entitlement service that uses your data and rules and that you can replicate to as many clouds, continents, regions, availability zones as you need. Entitlements can be updated without re-deploying any applications.

  • Centralized Management: Centralized policy authoring, data management, and decision logs without sacrificing physically distributed enforcement. Decisions can be audited and analyzed centrally. Governance over Entitlements, how they are changed, and their roll-out are handled uniformly across all applications.

  • Performance/Availability: Run an instance of the Entitlements service as close to the applications that need them as you like and rest assured that the distributed policies/data will be kept up-to-date. Entitlements can be controlled in large part by existing systems of record like LDAP and AD while still preserving tight controls over the load and access to those systems.

  • Development: From simple to complex authorization, implement the complexity of policy away from the application code into policy-as-code on top of a widely-adopted open standard, OPA. Entitlements can be read and written by users who are not developers.

  • Predictive Impact Analysis: Understand the impact of a policy or data change before you deploy it.

Concepts​

This section describes the concepts used in Entitlements system type.

System​

An Entitlements System represents a logical unit (for example, an application) that performs authorization.

Stack​

A 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. Stacks may also be used to enforce compliance regulations across a set of Systems, for example, the IAM team may own a Stack and use that to grant access to resources based on organization-wide IAM permissions. To integrate with a Styra DAS Entitlement System, applications must be updated to make authorization requests to OPA when subjects perform actions.

Requests​

A Request asks if a subject can perform an operation, and may optionally return a set of Entitlements.

By default, an Entitlements system supports three input fields: action, resource, and subject. Values for these three fields should be strings, for example:

{
    "action": "GET",
    "resource": "/v1/systems/prod-cluster",
    "subject": "alice@styra.com"
}

The action specifies the type of access being performed, for example, this may be an HTTP verb like GET or a higher-level action like read. The resource is the identifier of the object being accessed. This can be an HTTP path like /v1/systems/prod-cluster or a higher-level resource like System.Configuration. The subject is the id of the user or service account performing the request.

An optional input field that may be used in some policies is the context field, for example:

{
    "action": "GET",
    "resource": "/v1/systems/prod-cluster",
    "subject": "alice@styra.com",
    "context": {
        "location": "Wonderland"
    }
}

Additionally, Entitlements systems can be extended to support any arbitrary input field. Entitlement systems are also compatible with applications that call into existing authorization systems. To integrate with such applications, you must implement a transformation policy that re-writes the existing input schema to the schema described above.

Data Model​

Entitlements Systems come with pre-defined policy snippets that work over an opinionated data model. To use snippets, import your data in a way that conforms to the Entitlements data model. To help get your data into Styra DAS in the Entitlements data model, Styra provides pre-built transformation policies for many data sources including LDAP, AD, SCIM, OpenAPI v2, and OpenAPI v3. Custom transformation policies on data sources are also supported.

To troubleshoot data source transformation policies, refer to Debug Data Source Transforms in the Entitlements System tutorial.

The Styra DAS Entitlements data model is designed to be flexible. RBAC and ABAC are supported simultaneously and almost any structured data can be used as additional context for authorization decisions.

The object package, which can be imported via the path data.object should contain data structured according to the Entitlements data model. The pre-configured snippets provided with the Entitlements System type rely on the data in the object package having this structure, and will not work correctly if this data is malformed.

note

All fields in the Entitlements object model are case-sensitive, including subject IDs, attribute names, and role names. If you are retrieving data from a case-insensitive system, transform your data to normalize the case of any identifiers to use within your Entitlements System. You can also use the lower or upper builtin functions in Rego.

Subjects​

Subjects are optional and represent users, groups of users, or service accounts. All subjects must have a unique id and subjects may optionally have attributes.

Users may optionally be defined in a virtual document data.object.users. This document is not required to be defined; however, some snippets depend on it and will not work correctly without users being defined.

For example, the following package defines three users, two of which have attributes.

package object

users := {
    "alice@styra.com": {
        "location": "Wonderland",
        "name": "Alice Liddell"
    },
    "bob@styra.com": {
        "contractor": true,
        "location": "US",
        "name": "Bob"
    },
    "diya@styra.com": {
    }
}

Groups are defined in the data.object.groups virtual document. Groups may specify inclusion by user id or by specifying membership-attributes, which dynamically selects users for membership in the group. If both users and membership-attributes are specified, the union of users matching either of those selectors is included in the group.

package object

groups := {
    "contractors": {
        "users": ["diya@styra.com"],
        "membership-attributes": {
            "contractor": true
        }
    },
    "managers": {
        "users": ["alice@styra.com"]
    },
    "admins": {
        "users": ["cecily@styra.com"]
    },
}

Given the users and groups above, the contractors group contains diya@styra.com and bob@styra.com. The user diya@styra.com is included in the group by explicit inclusion and bob@styra.com is included because that user has the attribute contractor: true, which is specified in the membership-attributes of the contractors group.

The final subject type is intended for automation accounts and is defined in the virtual document data.object.service_accounts. Service accounts must have a unique id and may optionally include attributes. Groups may contain service accounts as well as users.

The following Rego document defines two service accounts, once of which has an attribute.

package object

users := {
    "github-integration": {
        "external-system": true
    },
    "das-publisher": {}
}

Service accounts are optional, and if specified will be included in snippets that use subjects.

Resources​

A Resource is an unique object that can be accessed. Resources are optionally specified as an object in the virtual document data.object.resources. Resources may optionally have attributes, which may be used in ABAC policy snippets.

For example, the following Rego package defines two resources with ids /cars and /trains, and /cars has a single attribute.

package object

resources := {
    "/cars": {
        "public": false
    },
    "/trains": {}
}

Often all resources are not known ahead of time, as they may contain variables such as UUIDs or usernames. In such cases, globs may be used to specify a set of resources. For example, an HTTP resource may be of the form /api/{id} and all possible ids are not known because they come from user input. This is specified by using resource id /api/*.

Additionally, it is possible to provide the name of resource variables, which can then later be used in policy snippets. This is done with a special attribute _variables, which maps variable positions to names. In the previous example, this attribute would be the map {2: "id"}, which means that the variable in the second segment of the resource is named id.

The following is an example of resources

package object

resources := {
    "/cars": {
        "public": false
    },
    "/cars/*": {
        "_variables": {2: "id"},
    },
    "/cars/*/status/*": {},
    "/trains": {},
    "/trains/*": {},
    "/trains": {}
}

Policy Models​

The Styra DAS Entitlements system type gives you pre-built policy snippets to implement a variety of Policy Models, such as

  • Role-based access control (RBAC)
  • Attribute-based access control (ABAC)
  • Time-based access control
  • Location-based access control
  • You can write a custom policy model using Rego.

Implementing RBAC​

To implement RBAC, you will need to map subjects to roles through role bindings.

A role defines a set of permissions over resources and a role binding attaches a role to a set of subjects. Users and service accounts that belong to groups inherit the permissions of those groups.Group membership may be specified explicitly or by attribute matching. Figure 1 shows the RBAC model.

Figure 1 - RBAC ModelFigure 1 - RBAC Model

Roles​

Roles define permissions over resources, and a permission is the set of actions permissible over a set of resources.

For example, a role single role with id id could be defined as:

{
    "id": {
        // allow grants access to resources selected by include and not selected by the exclude selectors
        "allow": {
            "include": [{
                "actions": ["action-id", "action.*"],
                "resources": ["glob/*/selector", "resource-id"]
            }],
            "exclude": [{
                "actions": ["action-id"],
                "resources": ["*", "resource-id"]
            }]
        },
        // deny removes access to resources allowed by any roles
        "deny": {
            "include": [{
                "actions": ["action-id"],
                "resources": ["**"]
            }],
            "exclude": [{
                "actions": ["action-id"],
                "resources": ["resource-id"]
            }]
        }
    }
}

Defined this way, roles provide a convenient way to express allow or deny lists over action/resource combinations. By default, roles do not do grant any permissions on their own. They need a role binding to be associated with subjects.

Role Bindings​

A Role binding attaches a role to a set of subjects. Role bindings can be expressed by subject ids or subject attributes or both.

For example, the following associates the role with id role-id with all subjects who have the attribute attribute-id with value value. It also associates role-id with the subjects user-id and group-id.

{
    "role-id": {
        "subjects": {
            "attributes": {
                "attribute-id": "value",
            },
            "ids": ["user-id", "group-id"]
        }
    }
}

When subjects are selected by both attribute and id, the union of subjects matching those selectors are bound to the given role.

Architecture​

The Styra DAS Entitlements system is intended for teams who either:

  • Need a cloud-native Entitlements service and intend to modify their applications to decouple Entitlements

    OR

  • Need a cloud-native Entitlements service to complement their existing on-premises Entitlements system to accelerate the migration of on-premises applications to the cloud.

In both cases, there is a need to continue utilizing an existing system-of-record (such as LDAP, AD, or SCIM for groups, roles, and so on), so that the organization can continue meeting its regulatory requirements for managing Entitlements. Also, there is a need for a cloud-native service that can be replicated wherever needed to ensure application requests for Entitlements are highly performant and available.

Figure 2 shows how organizations manage Entitlements for their applications using a centralized service.

Figure 2 - Entitlements ManagementFigure 2 - Entitlements Management

The Styra DAS Entitlements system makes it easy to connect to existing systems of record. It provides an OPA-based cloud-native Entitlements service with simple instructions for how to run a replica of that service anywhere it is needed. Also, it implements the Entitlements logic on top of the systems-of-record data.

The OPA-based cloud-native Entitlements service can run anywhere (any cloud, any region, even on-premises). Figure 3 shows the architecture model when you replace your on-premises Entitlements service with the OPA-based Entitlements service.

Figure 3 - OPA-based Entitlements ServiceFigure 3 - OPA-based Entitlements Service