Are you considering implementing the OpenID Shared Signals Framework (SSF) but unsure if it’s the right fit for your organization’s security needs? This post aims to provide a straightforward overview of SSF and help you determine its suitability for your security strategy.
What is the Shared Signals Framework?
It is difficult for Organizations to protect themselves only based on the data inside their organization. SSF serves the crucial function of facilitating the exchange of security signals between two organizations in real-time or near real-time.
There are two protocols that comprise the SSF. – Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC) protocol.
Each signal is defined as a security event. Each event has a subject identifier.
CAEP events include, but are not limited to:
- Session revoked
- Token clams change
RISC events include, but are not limited to:
- Account Credential Change Required
- Account Purged/Disabled/Enabled
- Identifier Changed/Recycled
For instance, if one organization (the transmitter) issues a security event involving a specific user, such as credential revocation, the other organization (the receiver) where the same user holds an account can be promptly notified of this event using either the CAEP or the RISC protocols. These security signals empower the receiver organization to take appropriate actions, such as adjusting user risk levels, revoking access, or initiating re-authentication processes.
What is the difference between the CAEP and RISC protocols?
CAEP protocol handles real-time events, which are often numerous and include actions like session revocations and token claims changes. Think of CAEP events as session related. On the other hand, RISC protocol deals with events that do not require immediate action and are typically less frequent, such as account credential changes or account purges/disables/enables. Think of RISC events as account related.
What is a common Shared Signals Framework use case?
Revoking Access of Authenticated Users – one of the primary use cases of SSF is to facilitate the revocation of access for authenticated users, thereby bolstering authorization mechanisms. Consider the scenario where a user’s session is compromised, but they still have an active session across various platforms. To mitigate the risk posed by this compromised session, an organization (the transmitter) can utilize SSF to notify other relevant organizations (the receivers) of the session revocation event. By doing so, the receiving organizations can promptly revoke the user’s access privileges, effectively preventing unauthorized activity.
A prime example of this use case in action is the implementation by Cisco, where SSF is employed to revoke user sessions across different systems once a compromise is detected – Video.
The OpenID Shared Signals Framework offers a powerful mechanism for enhancing security across organizational boundaries by enabling real-time exchange of security signals. Whether it’s safeguarding against compromised user sessions or responding to security incidents promptly, SSF provides organizations with the tools needed to bolster their security posture in an interconnected digital landscape. If you’re looking to enhance your organization’s security capabilities, SSF is certainly worth exploring further.
What are the benefits of the Shared Signals Framework?
- Increased visibility – organizations will be able to get visibility about the security posture of their users or their users’ devices across multiple organizations
- Reduced operational overhead – organizations receive security signals and apply security controls in an automated way
- Enhanced Continuous Risk Assessment – organizations will be able to add a layer of security that covers the user’s session after authentication
- More secure Federated Identity Management – organizations can leverage the collective knowledge of all participants in the federated process
Additional resources:
Explainer video about Shared Signals Framework.