Skip to main content

SSO Configuration

SSO configuration is the portal workflow for connecting AxonFlow to an enterprise identity provider. It is designed for teams that want the customer portal to participate in their identity model instead of relying only on local passwords.

The current portal configuration surface includes:

  • GET /api/v1/sso/config
  • POST /api/v1/sso/config
  • PUT /api/v1/sso/config
  • PATCH /api/v1/sso/config
  • DELETE /api/v1/sso/config
  • POST /api/v1/sso/config/test
  • GET /api/v1/sso/audit
  • GET /api/v1/sso/providers
  • GET /api/v1/sso/providers/defaults
  • GET /api/v1/sso/sp-metadata
  • POST /api/v1/sso/fetch-metadata

What Platform And IAM Teams Do Here​

This workflow is where an identity or platform team:

  1. chooses a provider
  2. loads or fetches IdP metadata
  3. verifies the service provider metadata AxonFlow expects
  4. tests the configuration
  5. enables or disables the SSO configuration
  6. reviews audit data when login issues appear

That is a much more complete workflow than simply publishing a SAML ACS URL in a setup guide.

SaaS Versus In-VPC​

The portal frontend is deployment-aware. The SSO settings experience is organization-scoped in SaaS environments and more platform-oriented in In-VPC deployments. Either way, the operational pattern is the same: configure the provider from an authenticated session, then use the resulting SSO flow for user sign-in.

Metadata And Testing​

Two parts of the current implementation are especially useful:

  • SP metadata lets the customer see the AxonFlow entity ID and ACS URL that should be configured in the identity provider
  • configuration testing validates whether the portal can actually use the supplied IdP settings before a team rolls the change out broadly

That makes this page valuable for reducing rollout risk. Identity integrations often fail because teams publish partially correct metadata and only discover the mismatch during a live login attempt.

Permissions And Neighboring Surfaces​

The portal also uses the sso:configure permission for SCIM token management. That is a signal that SSO and provisioning should be treated as related access-control operations, not independent one-off features.

For most enterprise deployments, the right workflow is:

  1. configure SSO
  2. verify login behavior
  3. configure SCIM if automated provisioning is required
  4. align group or role mapping

Common Uses​

This page matters when:

  • enabling Okta, Microsoft Entra ID, Auth0, OIDC, or another SAML IdP for the first time
  • rotating certificates or metadata
  • debugging failed SSO handshakes
  • validating service-provider metadata after deployment changes
  • moving from password login to enterprise identity ownership
Last updated on