Zero Trust can help organizations reduce their attack surface and respond quickly to threats, but many companies still struggle to implement Zero Trust because security tools don’t reliably share signals. According to Accenture, 88% of organizations admit that they faced significant challenges when implementing such an approach. If the products cannot communicate, real-time access decisions will not work.
The Shared Signals Framework (SSF) aims to solve this problem with a standardized way to exchange security events. However, recruitment varies. For example, Kolide Device Trust currently does not support SSF.
Scott Bean, Senior IAM and Security Engineer at MongoDB, proposed a solution to the problem that provides an easy and intuitive way for teams to operate SSF across their environments.
This guide provides an overview of the workflow and step-by-step instructions for getting it up and running.
Problem – IAM tools do not support SSF
A core requirement of Zero Trust is continuous, reliable signals about user and device health. However, many tools do not support Continuous Access Evaluation Protocol (CAEP) SSF, making it difficult to share and act on these signals.
Teams often face three challenges:
Tools lack native SSF support Signal enrichment or correlation is required Managing SSF endpoints and token processing increases overhead
Without this interoperability, organizations struggle to enforce consistent policies. And in cases like Kolide Device Trust, important device events never reach systems like Okta.
Solution – SSF transmitter that converts Kolide issues into CAEP events
SSF is built on HTTPS requests, so the OpenID standard works with HTTP actions in Tines.
Scott developed a new workflow that integrates Kolide Device Trust with Tines, allowing them to send SSF signals to Okta. If the device is not compliant, Kolide sends a message to the workflow via a webhook. Tines strengthens the signal, verifies that it can be linked to the user, builds a Security Event Token (SET), and sends it to Okta.
In this way, Tines acts as the connective tissue that makes SSF work across distributed IT environments, even when individual tools do not natively support the standard.
Tines can:
Receive signals from Kolide (and similar tools) via webhooks when a device becomes non-compliant. Enrich and correlate those signals (e.g. map devices to users). Generate and sign a SET that meets SSF specifications. Deliver to Okta (and other identity providers) to enforce the required SSF metadata endpoints on Zero Trust hosts using API path prefixes, providing consuming systems with a standards-compliant location to fetch keys and decrypt tokens.
All of this makes zero trust enforcement faster, more reliable, and much easier to operate. IT teams can perform continuous real-time risk assessments of devices, respond quickly to threats, and adjust policies more flexibly. End users also benefit from automated remediation to optimize productivity and minimize IT intervention.
If you want to learn more about identity modernization, check out the Tines IAM guide to learn how the team is unifying device trust, access decisions, and least privilege enforcement through automation. Scott’s workflow is one of several real-world patterns under the hood.
Workflow overview
Tools needed:
Tines – Workflow orchestration and AI platform Kolide – Device reliability and posture monitoring Okta – Identity platform that receives CAEP events
Required credentials:
Tines API Key – “Team” scoped to the “Editor” role Kolide API Key – Read-only Kolide Webhook Signing Secret
Required resources:
An Okta domain (such as example.okta.com or example.oktapreview.com) or a branded domain.
structure:
This workflow creates a proof-of-concept SSF transmitter that can be registered with Okta and sends device compliance change CAEP events (sent as SETs) based on Kolide-generated issues. There are three elements:
1. Generate and save a SET signing key (SET is a signed JSON web token).
Create an RSA key pair and convert it to JWK format. Publish the public key for SSF recipients to verify the SET signature. Save your private JWK keyset as a Tines secret.
2. Expose the SSF transmitter API
SSF receivers (such as Okta) require:
A .well-known/sse-configuration endpoint that describes the transmitter A JWK endpoint that exposes the public key used to verify the SET signature A webhook that serves as the SSF API A trigger surface logic is returned A .well-known config logic returns the JWK
Once this is published, teams can register new SSF receivers with Okta at:
Security → Device Integration → Receiving Shared Signals
Then create a new stream using the API URL and the new `.well-known` endpoint.
3. Create, sign, and send SETs from Kolide events
Receive Kolide publication events via a webhook and validate them using a signing secret. Get device and user metadata from Kolide. Constructs a SET for device compliance change CAEP events. Sign the SET with the stored private key using the JWT_SIGN expression. Send the signed token to Okta’s security event endpoint.
This delivers real-time device compliance updates to Okta, allowing access policies to take immediate action.
Configuring a Workflow – Step-by-Step Guide
You can build and run this entire workflow using Tines Community Edition.
1. Log in to Tines or create a new account.
2. Navigate to the pre-built workflow in the library. Select Import. This will immediately display your new pre-built workflow.
3. Gather the required credentials
Tines API key (team scope with editor role) Kolide API key (read-only) Kolide webhook signing secret
These ensure that calls to Kolide are authenticated and webhooks are securely verified.
4. Gather the necessary resources
You will need an Okta tenant domain that looks like this:
example.oktapreview.com example.okta.com or a custom Okta branded domain
This domain is used when sending signed SETs to Okta’s security event endpoint.
Note: In the example provided, Scott is configured as a “push” provider rather than a “polling” provider, since the token is sent based on the incoming webhook, so there is no need to save state.
5. Generate a SET signing key
Create an RSA key using the Generate JWK Keyset action. Convert both public and private keys to JWK format (two event transformations). Store the resulting set of keys using a Tines secret.
This is required before Okta can accept and validate the SET.
6. Expose SSF transmitter API
SSF API webhooks include two branches.
.well-known endpoint trigger: Well-known event transform: Returns the SSF configuration that declares the transmitter’s capabilities JWKS endpoint trigger: JWK event transform: Returns a public JWK so that Okta can verify the signature
Once live, Okta can register this transmitter as a shared signal sender.
7. Connect Kolide and handle device issues
The Kolide integration flow follows these steps:
Webhooks: Kolide Webhook – Receives issue opened/resolved events Get device details – Get associated device metadata Device has user – Branching logic to check user is associated Get user details – Find user metadata in CAEP payload
Depending on whether the issue is new or resolved:
Build SET – Builds the CAEP device_compliance_change event. Sign the SET – Generate an SSF-compliant SET using the RSA private key you previously saved. Send SET – Sends the final signed token to Okta’s security event endpoint.
As soon as Okta receives and validates the SET, it updates the associated user’s risk level.
bring everything together
SSF exists to enable security tools to speak the same language and provide continuous insight into risk and device health. But when key tools don’t support standards, gaps exist and access policies lag behind real-world changes.
Tines bridges these gaps by enabling new intelligent workflows. These ensure that tools that do not support SSF can still send information in the same standardized way. By using Tines to generate, sign, and distribute compliance signals in real time, you can reap the benefits of SSF even if your source tools are not built for SSF.
If you’d like to try this workflow for yourself, you can do it in minutes using your free Tines account. And if you want to see how device state fits into your broader identity strategy, this guide to modern IAM workflows introduces practical patterns and real-world workflows like Scott’s that you can start building today.
Source link
