Skip to main content

Overview of DAS Entitlements System

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

The motivation for the DAS Entitlements system type is that many organizations are already accustomed to using a centralized Entitlements management system for their on-premise custom applications. Instead of hard-coding into every custom software application the rules and regulations about what users can perform which actions (and when), developers will instead integrate those custom applications with a separate system that handles all of those rules and regulations on behalf of the application.

Features

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

  1. Policy management lifecycle: Styra DAS provides policy lifecycle management capabilities, such as 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.

  2. Data management: It 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 ActiveDirectory (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.

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

  4. API driven: Styra DAS is 100% API driven with on-premise or cloud-based SaaS offering. It integrates with existing tools like Git, Prometheus, Kubernetes, S3, Datadog, Slack, and so on.

Benefits

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Predictive Impact Analysis: Understand the impact of a policy or data change long 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 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"
}
}

Additional, 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 these snippets, you will need to import your data in a way that conforms to the Entitlements data model. To help get your data into DAS in the Entitlements data model, we provide pre-built transformation policies for many data sources, such as LDAP, AD, SCIM, OpenAPI v2, and OpenAPI v3.

The 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 Entitlements data model must be implemented as a Rego package named object, so other packages import it as data.object. This data is entirely optional; however, pre-configured snippets rely on it and so some sections are required, depending on the policy you wish to enforce.

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 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 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 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-premise Entitlements system to accelerate the migration of on-premise 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 Management

The 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-premise). Figure 3 shows the architecture model when you replace your on-premise Entitlements service with the OPA-based Entitlements service.

Figure 3 - OPA-based Entitlements Service