CAEP Hub Action Overview

CAEP Hub Actions are the things that actually go out and do all of the work for your CAEP Hub Rules, based on the state of a Trigger. SGNL has developed tens of out of box actions that use standards-based technology such as CAEP and Shared Signals Framework, as well as proprietary actions against leading SaaS vendors such as Microsoft Azure, AWS, Salesforce, and more. You can also create your own Actions using SGNL’s flexible Generic Webhook action that is available to all Protected Systems, enabling you to customize the Action as needed.

Getting Started with Actions

Protected System Type

Actions are associated with Protected Systems, and the Type of Protected System helps to define which Actions are available. If you’ve created the Protected System using one of the systems from the SGNL Protected System Catalog, the type should be set correctly, but if you need to update or change it, simply go to the Settings page of the Protected System and update the Type field.

Common Types:

  • CAEPTransmitter-1.0.0 - SGNL as a CAEP Transmitter, this contains all of the standards-based CAEP Events that can be used as actions in SGNL
  • AzureAD-1.0.0 - A rich set of actions to make changes to users and groups in Entra ID as well as to manage sessions in Entra ID and connected services (e.g. Office 365, Azure Portal/Infrastructure, and Dynamics)
  • AWS-1.0.0 - Actions to manage AWS Sessions in real-time, to restrict access to specific roles or resources inside of AWS
  • Okta-1.0.0 - A rich set of actions against Okta’s proprietary APIs, as well as for sending Security Event Tokens for Okta’s proprietary message types, such as User or Device Risk

Protected System Actions Configuration

Once you’ve selected your Type of Protected System – it’s time to configure some of the details about your specific implementation of the Protected System. Let’s use an example of Entra ID to start, but more details are later in this document if you’re creating actions against some other system

From the Entra Protected System:

  1. Select the Actions tab
  2. Specify the Address of the integration as https://graph.microsoft.com/v1.0, addresses for some of the other common providers are included below
  • Note The Address for an individual action can be overriden within the Action itself, but an address value is required on the Protected System.
  1. Specify the Authentication Method, for Entra ID SGNL supports both the Client Credential and Authorization Code Flow, simply fill out your Authentication Details, or read more on the Entra ID Protected System configuration page
  • Reminder: If you’re using the Entra ID Authorization Code Flow, ensure you configure the offline_access scope in addition to the Microsoft Graph API Default scope https://graph.microsoft.com/.default
  1. Once configured, you’re ready to start configuring Actions on Rules

For Protected Systems using the Bearer Authentication method, ensure that you prefix the token with the Token Type, in most cases this will mean a Bearer prefix before the token (e.g. Bearer eyJ...). In some cases however, this may be another prefix before the token, e.g. Okta (SSWS SomeToken), PagerDuty (Token token=aX...), and so on.

Using Actions and Action Parameterization

Now that you’ve got at least one Protected System configured for Actions, you’re able to start using those Actions in Rules. Parameterization is an incredibly important part of SGNL’s CAEP Hub, it lets you take arbitrary attributes from the Graph (or allows attributes to be generated) and then used in Actions.

One thing to consider as part of developing your triggers, is that your trigger will need to contain at least the entities that hold the attributes/parameters that you care about, and should be connected via relationships in the graph to the objects you’re monitoring for changes (or be those object directly).

In the case of the below, we’re going to use an Entra ID User Principal Name (UPN) – in many cases, this will simply be a user’s email address, which should be present on many of the user nodes in the graph, but sometimes that’s not the case. Make sure that you have a reliable way to find the user’s UPN (the most reliable way is simply including the Entra ID User in your trigger, attached to other nodes via a relationship like SameAs).

Using parameters is simple, simply add the parameter syntax into an action by itself, or surrounded by other text/JSON as you see fit. Parameterization syntax can be automatically inserted by hitting the + button on the input field, or typed using the syntax {$.{{NodeName}}.{{AttributeName}}} or optionally some additional operation such as {$.{{NodeName}}.{{AttributeName}}.{{Operation}}}. Supported Operations against Graph Nodes include, Sum, Min, Max, and Count as outputs of parameters.

One or more parameters can be added to any field in an Action, including the Address Override field in a given action, meaning you can dynamically change the contents of requets based on the data returned from a trigger.

An example of a parameter for a Trigger that contains an Entra ID User (where the Node Name in the trigger is EntraIDUser) could be {$.EntraIDUser.userPrincipalName} where you want the UPN of the User to be sent as a parameter.

From within CAEP Hub, select an already created Rule, or create a new one with the appropriate nodes and relationships:

  1. Select ‘Add Action’
  2. From your list of Protected Systems, select one and review the list of Available Actions – if you’re using the Entra ID Protected System, you’ll have a collection of proprietary actions, as well as the ability to add a Generic Webhook
  3. When you select an Action (let’s start with the Entra ID Session Revoke), you’ll have a field where you can add relevant details, in this case it will be the User’s User Principal Name
  • Note: all fields can contain parameters, plain text, or JSON depending on what’s required by the Protected System you’re sending the action to
  1. In the userPrincipalName field, click the + button to add a reference to the node in the graph that would contain the user’s UPN, i.e. {$.EntraIDUser.userPrincipalName}
  2. Click to Save the rule, and you’re all done

SGNL Action Parameters

While parameters are mainly designed for using attributes on nodes in the SGNL Graph, we also provide a number of helper parameters for use in your actions. These include:

  • The Current Time: {$.sgnl.time.now}
  • A Random UUID: {$.sgnl.random.uuid}

Say for example you want to revoke all sessions in AWS as of the moment the action fires, you could use the below in your conditions statement:

{"DateLessThan": {"aws:TokenIssueTime": "{$.sgnl.time.now}"}}