Skip to main content


Requests represent what the application sends to the OPA-based Entitlements service when asking for an Entitlement decision. Styra DAS Entitlements dictates that the request provides a subject, action, and resource.

The Styra DAS input structure is supports various request types. By default, the Styra DAS Entitlements system supports the following three basic input fields:

"action": "GET",
"resource": "/v1/systems/prod-cluster",
"subject": ""
  • 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. Actions can be defined within data sources so that they can be application specific.
  • resource: Specifies the identifying of the object being accessed. This can be an HTTP path like /v1/systems/prod-cluster or a higher-level resource like System.Configuration.
  • subject: Specifies the id of the user or service account performing the request.

Styra DAS Entitlements provides pre-built Rego rules that leverage the known schema for the input document. Different rules rely on different parts of the input document.


See Policy Snippets for details on which parts of the input you need to provide.

You can add your own input fields; however, the pre-built policy snippets will not understand them, and you will need to write custom Rego to take advantage of the additional inputs.

Transform a Request

If the input format described above does not match what your applications are sending as part of an entitlement request, you can transform the input by writing custom Rego by performing the following tasks:

  1. Create a Rego file in the folder transform/newinput. An example transform is provided in the default transform folder.

  2. Define a variable called newinput that captures the information provided by the application, but represents it in the input structure described above. For example, if your input provided a user field instead of the subject field described above, you can write the following Rego to transform it.

    package transform.newinput

    newinput["subject"] = input["user"]
    newinput[x] = input[x] {
    x != "user"
  3. Click on the Preview button to check if your transform is working properly and supplying the actual input that your application is providing.

If you perform any type of additional processing within this transformation then you will not notice the transformation within the resultant authorization decision. This behavior is caused because the transformed input document is not stored in the final decision, but only the original requesting input document is retained.