Elgato_dark/fleet
1
0
Fork 0
mirror of https://github.com/fleetdm/fleet synced 2026-05-22 00:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 106

Added SSF to Okta research doc. (#33720)

Browse source 
<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** Resolves #32766
This commit is contained in:
Victor Lyuboslavsky 2025-10-03 08:16:41 -05:00 committed by GitHub
parent ff333f7751
commit 5ff5332026
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 26 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
docs/Contributing/research/orchestration/okta-conditional-access.md
View file

@ -161,13 +161,37 @@ sequenceDiagram
## Other alternatives to Okta Verify
### Shared Signals Framework (SSF)
**Overview.** [SSF](https://openid.net/wg/sharedsignals/) is an OpenID protocol for transmitting security events and posture signals between providers asynchronously. It enables continuous monitoring by broadcasting events like "device became non-compliant" to multiple receivers (Okta, Cisco, SGNL, Google Workspace, etc.).
**Why it doesn't solve our use case.**
SSF has no native mechanism to identify which device the user is logging in from during authentication. The critical gap:
1. **Device identification problem**: SSF events are keyed by user identifiers (email, subject) or session identifiers, but there's no standard way for the browser to communicate "I'm device X" to Okta during login.
2. **No presence proof**: Unlike Okta Verify (which proves device presence via localhost/deep links) or our mTLS approach (which uses client certificates), SSF has no mechanism to link the browser session to a specific Fleet-managed device.
**When SSF is useful.**
SSF would be valuable for continuous monitoring use cases:
- Notifying Okta when a Fleet device becomes non-compliant (triggering session revocation)
- Sharing security events with other systems (EDR, SIEM)
- Multi-vendor risk correlation
**Recommendation.** SSF does not replace the need for synchronous device identification and authentication. Consider SSF as a future enhancement for continuous monitoring, but it cannot substitute for our possession factor + mTLS approach.
### Other certificate-based alternatives
* Issue a device certificate if it is passing policies, and use the certificate as a factor in Okta flow.
* [Use your own certificate authority for managed devices](https://help.okta.com/oie/en-us/content/topics/identity-engine/devices/config-customer-provided-ca.htm)
* Cert remains valid until revoked/expired (potential security gap for several hours)
* Okta checks CRL (Certificate Revocation List) endpoint a few times per day
* Can't show custom remediation messages
* Using inline hooks
* Can work for OIDC to block access, but not for SAML.
### Inline hooks
* Can work for OIDC to block access, but not for SAML.
---