Repository navigation
Experimental SSF Support #48840
Replies: 2 comments 4 replies
ABM integration report: Apple posts stream registration to a host-rooted pathSetup: Keycloak 26.7.0, Symptom: ABM setup fails at the SSF validation step with "We were unable to connect to your Identity Provider as we could not verify the provided SSF configuration." Root cause: Apple's (legacy SSE) client posts stream registration to the host root, ignoring the realm-prefixed endpoint advertised in the ssf-configuration metadata: "POST /ssf/transmitter/streams HTTP/1.1" 404 Keycloak serves this at Workaround: a reverse-proxy rewrite that prefixes Second gotcha: the next attempt failed with 400 because "Valid push URLs" was empty — and since Apple registers its push endpoint programmatically, the admin never sees the URL beforehand. For us this value works: |
|
@ahmeij If you think there is a bug in the SSF implementation, please open a bug report with steps to reproduce. Thanks! |
|
The Apple Business support works for me without a reverse proxy workaround. |
|
Use case: Notifying relying parties about revoked sessions so that they can stop trusting those sessions, e.g. stop accepting access tokens associated with those sessions. Problem: When all sessions of a user are revoked by an admin (via What can be done: When
IMHO, the last point is the one that is worth addressing. Having mapper return a list of SETs instead of just one would make it more flexible and future-proof, allowing it to deal not only with multi-session revocation event but also with other events that may justify "splitting". After that, adjusting |
|
@kirmerzlikin Can you create an enhancement issue for this? Please include as much info as you can about your use case. Mention @ssilvert and @thomasdarimont so we will see it. |
|
I see your point regarding ALL not being explicit enough, but I wonder if the combination of ALL and event_timestamp is not enough here. If you receive an session revoked event with ALL, then you can just treat all sessions created via the respective issuer before the event_timestamp as revoked. This should be fairly easy to interpret. I'd avoid sending a potentially massive amount of individual session revoked events which might overwhelm the receivers. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In this discussion we want to gather feedback for the experimental SSF Support in Keycloak 26.7.x.
SSF is shipping experimental specifically so we can shape it around real integration experience before it's promoted
to a stable feature. We'd particularly like to hear from you if any of the following applies:
the receiver authentication options.
surfaced as CAEP / RISC events (or as custom event types via the SPI).
All reactions