Configure a shared signal receiver

Early Access release

Admins can configure an integration that allows Okta to receive security-related events from a security event provider's apps. Integrations are based on the OpenID Shared Signals Working Group’s Continuous Access Evaluation Protocol (CAEP). Setting up the integration requires admins to gather configuration details from the security provider that sends the signals to Okta. After the stream is configured in the Admin Console, Okta can ingest the risk signals as events.

These signals inform the risk engine and are reported as entity risk detections (user.risk.change events) in Okta. Okta also publishes the received Shared Signals Framework (SSF) CAEP event encapsulated in a System Log event called security.events.provider.receive_event. The risk assessment communicated in the user.risk.change event is used by the entity risk policy to configure actions using Workflows, session revocation, or Universal Logout. This ensures that an entity's risk is informed by interactions with threat surfaces outside the scope of identity, like activity on a device, on the network, within an application, or with data.

The SSF integration enables the Okta user to be protected, even if they aren't interacting with Okta.

Before you begin

To receive risk signals from security events provider, you need to configure the SSF Transmitter. This is done in the security provider app, which provides a JWKS (JSON Web Key Set) that's used in the Admin Console to configure the integration with the security provider's app. Refer to your security provider's documentation for SSF Transmitter configuration.

Security events providers

Okta can receive signals from the following security events providers. Refer to the security event provider's documentation to configure the app as an SSF Transmitter and receive signals in your org.

Security providers

App

Jamf Jamf Security Cloud (Jamf Radar)
Netskope Netskope Cloud Exchange
Palo Alto Networks Cortex XSIAM
Zscaler Deception
SGNL All products
Zimperium Mobile Threat Defense (zIPS)

Configure the security events provider app

Before you can start to see security events in Okta, you must prepare the security provider's app to share information with Okta. In the security provider's app, you generate the Issuer and JWKS URLs that secure the transmission of signals to your Okta org.

These steps walk you through setting up Okta as an SSF receiver with Jamf as a transmitter. Refer to the documentation of your security provider's app to learn more about signal sources, the Shared Signals and Events Framework (SSF), and configuring the security provider application to share signals with Okta.

  1. Sign in to Jamf as a super admin.
  2. Open Integrations SSF Streams.
  3. Click Create new SSF stream.
  4. Enter the audience, which is the URL that identifies the stream. In this case, the audience is your Okta tenant address, for example, https://your-org.oktapreview.com or https://your-org.okta.com.
  5. Click Create.

When the stream is created, Jamf returns a token that's used by SSF receivers that support auto-discovery. This token isn’t used by Okta. Instead, copy the Well-known URL to enter in the Admin Console.

Receive shared signals

Enable your Okta org to receive security signals from provider apps using the SSF. The SFF helps create a network between your security provider applications, continuously sharing security information with Okta to prevent and mitigate security threats to your users.

  1. In the Admin Console, go to Security Device Integrations.
  2. Click the Receive shared signals tab.
  3. Click Add stream.
  4. Enter an Integration name.
  5. You can set up the integration with a Well-known URL or the Issuer URL and JWKS (JSON Web Key Set) URL, which come from the transmitter of the signals you’re configuring Okta to receive. Select the integration, which in this example is the Well-known URL.
  6. Paste the URL from the security provider application into the Well-known URL field.
  7. Click Save.

If the stream is created successfully, it appears in the stream list in the Admin Console. The status is set to Active by default.

If Okta was unable to create the stream due to an error, a message appears requesting that you add the stream again. Check the URL you entered to ensure it's correct before attempting to connect the stream again.

Stream actions

When a stream has been created, it appears in the stream list. All added streams are Active by default. If you want to edit, deactivate, or remove a stream, click Actions and select an option from the dropdown menu.

Monitor stream events

After you configure an SSF stream, Okta receives Security Event Tokens (SETs) that comply with the CAEP. SETs inform how Okta calculates entity risk, and can be viewed in security.events.provider.receive_event System Log events.

There are several ways that an admin can monitor an SSF stream:

  • View the SET content in security.events.provider.receive_event System Log events.
  • Ensure these are encapsulated in user.risk.change events.
  • Refer to security provider documentation on the type of risk events supported for transmission that can be received or seen within Okta.
  • Use the Entity risk report to see the entity risks that were detected by Okta.

Related topics

Detections

Identity Threat Protection with Okta AI dashboard widgets

Identity Threat Protection with Okta AI reports

System Log events for Identity Threat Protection with Okta AI