Enhancement: Shared Signals Framework Receiver - New Event Types and More!

Announcements Product News
,
1

:double_exclamation_mark: The SailPoint Shared Signals Framework (SSF) receiver now supports Continuous Access Evaluation Profile (CAEP) events, including Session Revoked and Credential Change. Additionally, you can now customize the format of the Subject ID for the SSF Receiver and use OAuth 2.0 JWT - Client Credential grant type for authentication.

Description

The SailPoint Shared Signals Framework (SSF) Receiver now supports the CAEP events Session Revoked and Credential Change. When a security event is received, it is enriched with the identity context by automatically correlating it to an identity.

CAEP Session Revoked Events:

  • Session Revoked events are standardized security signals used to immediately terminate user sessions across different applications and services. As part of the Shared Signals Framework, this event type allows an Identity Provider (IdP) to tell a Service Provider (SP) that a user’s session is no longer valid, ensuring that access is revoked in real-time rather than waiting for token expiration.
  • For example,
    • A contractor’s contract ends at 5:00 PM on Friday. HR updates the identity system, setting the user to inactive. The Identity Provider immediately triggers a session-revoked event to all subscribed applications (e.g., Salesforce, GitHub, Slack). Even if the contractor is logged into Salesforce and GitHub, those systems receive the signal and immediately terminate the active session, preventing further access.
    • A user’s credentials are leaked, or a Threat Intelligence system detects suspicious login behavior from a strange location. The security system triggers a session-revoked event for the user. The SaaS applications (e.g., Okta) receive the signal, which results in the invalidation of all active sessions and refresh tokens, requiring the user to re-authenticate with higher-assurance credentials.
    • A user’s laptop is connected to corporate systems, but the Malware Detection System or MDM detects that the firewall has been disabled or a malicious app was installed. The MDM notifies the IdP and SaaS apps via a CAEP event, indicating a Device Compliance Change that warrants an immediate session-revoked event. Applications like Slack or Jira automatically terminate the session, preventing the user from accessing corporate data until the device is remediated.
    • A security admin identifies that a user is part of a security incident and must be removed from all systems immediately. The admin revokes the user’s refresh tokens in their IdP, which triggers a revocation signal to downstream service providers. The service provider immediately rejects the next API call or access request from that user.

CAEP Credential Change Events:

  • Credential Change event is a standardized security signal sent from an Identity Provider (IdP) or service to relying parties (applications) to indicate that a user’s authentication credentials have been modified. This event enables immediate, real-time security action, such as terminating active sessions, in response to potential account compromises or administrative actions.
  • For example,
    • If an administrator detects an account compromise and forces a password reset, a credential change event is sent, triggering immediate termination of all active sessions across connected applications.
    • If a user’s credentials are changed or revoked during off-boarding, CAEP ensures that access is immediately revoked, rather than waiting for a session token to expire.
    • A user changing their registered MFA device might trigger a credential change event, prompting apps to require a fresh, high-assurance authentication.

Workflow Triggers and Templates:

CAEP Session Revoked
CAEP Session Revoked660×1012 35.6 KB

CAEP Session Revoked

CAEP Credential Change
CAEP Credential Change650×1012 36.1 KB

CAEP Credential Change

  • This support includes two Workflow triggers and two Workflows templates:

Support iss_sub format for Subject Identifier

  • Subject identification in the Shared Signals Framework Receiver now supports the Issuer and Subject Identifier Format (iss_sub) in addition to the Email Identifier format. You can set the Subject ID to the Account ID of a selected Source so that events are correlated with Identities through the associated account; otherwise the user’s email address is used as the Subject ID.

Support JWT Authentication Types

  • SSF Receiver now supports JWT - Client Credentials grant type.
  • This provides additional flexibility to connect with systems that supports OAuth 2.0 client credentials grant type.

Documentation

Release Details

  • Identity Security Cloud - Available (SaaS).

Note: Atlas Enterprise features are available for add-on purchase for Business and Business Plus customers. Please contact your CSM for more information!

2

I am a bit confused here.

You mention terminating user sessions, but the screenshots show the action of disabling accounts, which are different things.

  1. It could be that we would like to terminate an active session of a user on a specific application, or terminate all active sessions from a user on a specific application (you could have multiple sessions if you are logged in from multiple laptops/browsers/etc.). In this case the account should stay enabled. Simply starting a new session would work.
  2. It could be that we would like to disable an account of a user. Depending on the application It could be that there is still a session active which could continue for a while.
  3. It could be that we would like to disable a users account and terminate all their sessions.

Wouldn’t it make sense that we could choose the option based on the policy we have? Perhaps a user just got provisioned important access on an application, which means the next time they login, they get more strongly authenticated. To ensure the current sessions, which could have been less strongly authenticated can’t use this gained access yet, we will kill the sessions to enforce reauthentication, now using stronger authentication due to the enhanced access of the user.

Is it the job of an IGA solution such as ISC to kill active sessions of other applications?If so, should for example the Web Services and Web Services SaaS connectors be updated to support the HTTP operations “kill active session given by the session id” and “kill all active sessions of identity”?

But another topic I think would be important here is what to do with ISC as Service Provider itself?
Suppose our identity provider, or our SIEM solution, or maybe even ISC itself, discovers that something strange has happened in ISC. For example:

  1. An identity bypassed SSO using this trick while the identity is not labeled as firefighter identity by the customer).
  2. The SIEM solution has used behavior analytics to determine that the user behind the laptop running the session has changed.

Suppose that the SIEM solution would like to immediately delete this session to enforce reauthentication. The identity should stay active, reauthentication is allowed. Which ISC API can be called for this?

And in which ways can ISC assist in triggering SSF events? For example, if someone logs into ISC using the SSO bypass. Can such an event be immediately be triggering actions, where we check if a session should be terminated? And preferably in such a way that the identity logging in can’t possibly terminate those actions first.

I would love to see documentation and examples on the cases mentioned above, provided SailPoint supports it.

Kind regards,
Angelo

1 Like
3

Thank you for the information

4

What are the applications that support these SSF events and what configurations need to do in those apps?