SAML 2.0 Authentication

SAML 2.0 is the right fit when an organization wants AxonFlow access to flow through the same identity provider and review processes it already uses for the rest of its internal platforms.

For enterprises, this matters because the question is usually not just "can users sign in?" It is:

• can security own identity policy centrally?
• can users sign in with the same corporate identity they already use elsewhere?
• can platform teams avoid managing a parallel local-auth system?
• can access, audit, and offboarding align with company standards?

AxonFlow supports SAML 2.0 in Enterprise for that reason.

Where SAML Fits

SAML is most useful when AxonFlow becomes a shared internal product rather than a one-team experiment.

Typical triggers include:

• several teams need access to the same customer portal or governance tooling
• security requires federated identity instead of manually managed local accounts
• access reviews and user lifecycle need to align with corporate identity systems
• the trial is moving toward a real production deployment

That is why SAML is a meaningful enterprise feature, not just another authentication checkbox.

Supported Identity Providers

AxonFlow’s SAML docs and operating model are aimed at the identity stacks enterprises already use:

Provider	SP-Initiated	IdP-Initiated
Okta	✅	✅
Microsoft Entra ID	✅	✅
OneLogin	✅	✅
Ping Identity	✅	✅
ADFS	✅	✅
Shibboleth	✅	✅

Common Deployment Pattern

The most common pattern is:

1. AxonFlow is configured as the SAML service provider
2. your corporate IdP is configured to trust AxonFlow
3. users sign in through the IdP they already use for internal applications
4. access is governed through enterprise identity controls instead of stand-alone credentials

That makes SAML especially attractive for companies that want AxonFlow to feel like part of their existing platform estate, not an isolated AI tool.

Flow Options

SP-Initiated

The user starts in AxonFlow, which redirects them to the identity provider.

IdP-Initiated

The user starts in the corporate identity portal and launches AxonFlow from there.

Both patterns matter in real deployments:

• SP-initiated is common for engineers bookmarking the product directly
• IdP-initiated is common for enterprise access portals and internal app launchers

Configuration Concepts

SAML setup usually revolves around these fields:

Setting	What it means
Entity ID	unique AxonFlow service-provider identifier
ACS URL	assertion consumer service endpoint
IdP metadata	identity-provider configuration and certificates
signing certificate	trust material used to validate assertions

Enterprises also usually care about:

• attribute mapping
• group claims
• role mapping
• just-in-time provisioning behavior
• certificate rotation and expiry handling

Certificate Operations Matter

SAML outages often come from certificate lifecycle issues rather than protocol misunderstandings. That is why certificate rotation deserves explicit attention in the docs.

Step	Recommended timing
Generate replacement certificate	about 30 days before expiry
Upload and test the new certificate	before cutover
Update the IdP trust config	before the current cert expires
Promote or switch traffic	during the overlap window
Remove the old certificate	after the transition is stable

This is also where enterprise identity ownership matters. In large companies, the AxonFlow team is often not the same team that owns the IdP.

What Engineers Usually Need To Know

Senior engineers reviewing SAML are usually checking three things:

1. Does AxonFlow fit into our existing IdP without a custom identity project?
2. Can we map users and groups cleanly enough for real operations?
3. Is there enough operational detail that security and IT can support it later?

If the answer to those questions is yes, SAML becomes one of the strongest signals that the product is ready to live inside a real enterprise environment.

Enterprise Feature

Capability	Community	Enterprise
SAML 2.0 authentication	❌	✅
SP-initiated SSO	❌	✅
IdP-initiated SSO	❌	✅
JIT provisioning and group mapping workflows	❌	✅

SAML is a good example of the overall AxonFlow journey:

• Community is great for technical validation and local build-out.
• Evaluation helps prove governance and workflow features.
• Enterprise is what most larger organizations need when identity, access, and operations must align with company standards.

Related Documentation

• Single Sign-On for the broader SSO overview
• SCIM Provisioning for automated user lifecycle workflows
• Identity Overview for access and identity architecture
• Enterprise Overview for the enterprise operating surface