Creating SecureAuth policies in the Visual Policy Editor

When creating policies, you can match values to a pattern using the * character. Consider the policy comparator below:

{
  "fields":[
    {
      "field":"sub",
      "comparator":"equals",
      "value":"admin-*"
    }
  ]
}

Such comparator matches all values with the admin- prefix, such as admin-123.

In the editor UI, the above implementation would look as follows:

If you want the * character to be interpreted literally, escape it with \ as shown below:

{
  "fields":[
    {
      "field":"group",
      "comparator":"equals",
      "value":"\*"
    }
  ]
}

Such comparator matches * only.

Attribute validator is a generic validator allowing you to compare any source valid for the selected policy type

against any target valid for the selected policy type. Note that it might be easier to add and set up dedicated validators, where you have fewer source/target options.

In the video below, we are creating a policy checking if the request comes from a client application registered within a specific tenant.

Authentication context validator allows you to check an authentication context attribute against

In the video below, we are creating a policy checking that the IDP used to authenticate is registered in SecureAuth under the name github.

Client validator can validate the client context attributes in the request, passed in the contexts.client object. This way, you can verify any client registered in SecureAuth. For a list of client parameters, see the Client API documentation.

In the video below, we are creating a policy checking a specific client attribute (attribute_name). We expect this attribute to have a specific value.

This policy passes when the following client data is present in the request:

"contexts": {
        "client": {"attribute_name": "value"}
  }

Developer validator can validate the developer context attributes in the request, passed in the contexts.developer object.

In the video below, we are creating a policy checking a specific developer attribute (attribute_name). We expect this attribute to have a specific value.

This policy passes when the following developer data is present in the request:

"contexts": {
        "developer": {"attribute_name": "value"}
  }

Embedded policy validator allows you to pick another policy of the same type and resolve it within this validator. This way, you can nest policies within other policies.

Authentication factors validator checks if the user has completed the MFA process and prompts the user to do so if they didn't.

ID token validator compares an ID token attribute to a specific value or another ID token attribute.

Request header validator allows you to check a specific header for value or presence. In the video below, we are creating a policy checking for a specific header value.

By default, the policy checks all of its validators and passes only if all of them are resolved as true. It is however possible to create a conditional policy which allows you to build if/else statements based on validators, as shown in the video example below.

The Fail and Pass validators end policy resolution.

The Signal validator is useful when your requests are protected via Signal Sciences, allowing you to check the Signal warnings in order to validate the policy. You can check for the presence or absence of warnings.

When client registration in SecureAuth is protected by a software statement assertion (SSA), you can use this validator to further restrict client registration based on certain parameters in the SSA, as shown in the video below.

This policy passes when the following client data is present in the request:

"contexts": {
        "softwareStatement": {"attribute_name": "value"}
  }