Skip to main content

AxonFlow v9.15.0 Release Notes

v9.15.0 is an SSO release. Interactive SAML login, which could not complete on self-hosted in-vpc deployments, now works end-to-end, and a first-time SSO user is assigned their group-mapped role on login instead of landing with no permissions. It is a MINOR by the semver policy: it adds new backward-compatible capabilities (SSO role auto-provisioning, telemetry-by-version) and relaxes a refusal; it removes nothing and requires no new credential. No migrations.

Am I affected?​

Self-hosted deployments using interactive SAML SSO login (in-vpc / enterprise) get the end-to-end login fix and role auto-provisioning. If you configured SAML SSO and login never completed, this release fixes it. You must set SSO_BASE_URL (see below).

Deployments using the governed /api/request plane get the relaxed empty-email behavior: a token with no email claim now proceeds org-only instead of receiving 403.

Everyone else: routine upgrade. No migrations, no configuration changes required.

Interactive SAML SSO login works end-to-end (in-vpc)​

Interactive SAML SSO login was broken in three independent places on self-hosted in-vpc deployments and could not complete. All three are fixed:

  1. Login could not start. The login URL was built from the org id, but the SAML routes key on the config's addressing key (the __platform__ sentinel in in-vpc). Login now uses the addressing key and initiates correctly.
  2. The assertion went to the wrong host. The AssertionConsumerService (ACS) URL was hardcoded to the public SaaS host, so the identity provider posted the SAML assertion there instead of to the customer's own portal. The ACS host is now derived from SSO_BASE_URL and recomputed on every request, which also self-heals any ACS URL stored against the old hardcoded host (no re-save needed).
  3. The session was unreadable. The callback wrote the session into tables the request validator never reads (and that no migration creates), so login returned a 500. The session is now written to user_sessions, the store the validator resolves through portal_session_lookup().
Self-hosted deployments must set SSO_BASE_URL

Set SSO_BASE_URL to your portal's external URL (for example https://portal.yourcompany.com) before configuring SAML SSO. If it is unset on a non-SaaS deployment, SAML assertions are directed to the default host and login will fail; the portal logs a loud warning at startup when this is the case.

Scope: this release fixes SAML SSO. Configure your identity provider (for example JumpCloud) as a SAML application. A native OIDC interactive-login flow does not yet exist and is tracked separately. See the SAML SSO setup guide for the JumpCloud walkthrough.

SSO users are assigned their role on login​

When the SSO configuration has Auto-provision users enabled, a first-time SSO user (one with no existing active role in the organization) is assigned the role mapped from their identity-provider group, or the configured default role. Previously the group-to-role mapping was computed but discarded, so a new SSO user landed with no permissions and every gated action returned 403.

The provisioning is assign-if-absent: a user who already has a role, from SCIM, manual assignment, or a prior login, is left untouched, so it never downgrades an existing owner or conflicts with SCIM. It does not remove roles when the identity provider removes a group; full add-and-remove membership lifecycle remains the job of SCIM group-to-role mapping. Deployments that need de-provisioning should run SCIM.

Governed /api/request empty-email now proceeds org-only​

v9.14.0 introduced a segment gate that fail-closed to 403 when a governed /api/request token carried no email claim. v9.15.0 relaxes this: an empty email now proceeds with org-only scoping, matching pre-v9.14 behavior. Segment-scoped policy targeting still requires an email claim. This affects only /api/request, not /api/v1/decide or the MCP planes.

Also in this release​

  • The internal telemetry digest breaks down usage by platform version.
  • The self-hosted upgrade preflight carries the v9.14.0 upgrade advisories (export admin authority, /api/request email-claim) and points at v9.15.0 as the release with the /api/request org-only fallback.

Before you upgrade​

  • No migrations. This release adds no schema and mutates no data.
  • If you use SAML SSO: set SSO_BASE_URL to your portal's external URL, and configure your identity provider as a SAML application. See the SAML SSO setup guide.
  • If you are already on v9.14.0/v9.14.1 and hitting the compliance-export 403 or the /api/request refusal: you do not have to wait for v9.15.0 to remediate. See the v9.13 to v9.14 upgrade guide, which covers the in-place mitigation (an admin X-User-Token for exports, and minting /api/request tokens with an email claim).

SDK and plugin compatibility​

No SDK or plugin changes are required. Clients compatible with v9.14.x are compatible with v9.15.0.

Last updated on