SAML single sign-on for AxonOps Cloud

SAML 2.0 (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an identity provider and an application. AxonOps Cloud supports SAML 2.0 single sign-on, so an organisation can authenticate users against its existing identity provider instead of AxonOps-managed passwords, and can assign AxonOps roles directly from identity provider group or role membership.

Enabling SAML for your organisation

SAML single sign-on is an additional feature available to AxonOps customers and is not enabled by default. To have it enabled for your organisation, speak to your AxonOps account manager.

Why use SAML

Compared with per-user AxonOps credentials, SAML moves authentication and access control into the organisation's existing identity infrastructure.

• One credential set: users sign in with the organisation's existing credentials; there is no separate AxonOps password to create, remember, or reset.
• Organisation sign-in policy applies: authentication happens at the IdP, so whatever the organisation enforces there (multi-factor authentication, conditional access, password policy) applies to AxonOps Cloud automatically.
• Credentials stay with the IdP: the user's password is only ever entered at the identity provider; AxonOps Cloud receives a signed assertion, never the credentials.
• Central access control: access to AxonOps Cloud is granted and revoked in the identity provider alongside every other application, rather than managed separately per user in AxonOps; a user removed or disabled in the IdP can no longer sign in to AxonOps Cloud.
• Roles follow directory membership: AxonOps roles are assigned through IdP role or group assignment (see the role reference below), so access levels are managed with the same process the organisation already uses.

For example, an organisation using Microsoft Entra ID monitors its Cassandra clusters with AxonOps Cloud. When a new database administrator joins, adding the user to the platform team's Entra ID group, which is assigned an app role carrying the dba value, is the only step required. At the first visit to https://<orgname>.axonops.cloud the administrator signs in with existing corporate credentials and multi-factor authentication and receives DBA access. When the administrator leaves, disabling the Entra ID account ends the ability to sign in to AxonOps Cloud, with no AxonOps-side cleanup.

How SAML sign-in works

Three parties are involved: the user, AxonOps Cloud (the service provider), and the organisation's identity provider.

1. The user opens https://<orgname>.axonops.cloud.
2. AxonOps Cloud redirects the browser to the identity provider's sign-in page.
3. After authentication, the identity provider returns a signed SAML assertion carrying the user's identity and AxonOps role values.
4. AxonOps Cloud validates the assertion and starts a session with the mapped AxonOps roles.

In more detail, the login is SP-initiated: it starts at the AxonOps Cloud URL, which redirects the browser to the IdP.

Vocabulary

A SAML integration involves two parties and a small set of artifacts exchanged between them.

• Identity provider (IdP): the system that holds an organisation's user identities, authenticates users (typically with the organisation's existing credentials and multi-factor authentication), and issues the SAML assertion. AxonOps Cloud supports Microsoft Entra ID, Okta, and JumpCloud as identity providers.
• Service provider (SP): the application that relies on the IdP to authenticate the user and consumes the assertion to establish a session. AxonOps Cloud is the service provider in this integration.
• Assertion: a signed XML document the IdP sends to the SP after authenticating the user. It states who the user is and, for AxonOps, which roles apply to the session.
• Entity ID: an identifier string that names a party in the trust relationship. SAML defines one for each side (the IdP Entity ID and the SP Entity ID), and the values entered in the AxonOps console must match the IdP-side configuration exactly.
• Reply URL / Assertion Consumer Service (ACS) URL: the SP endpoint that receives the signed assertion after the IdP authenticates the user. For AxonOps Cloud, this is https://<orgname>.axonops.cloud/login-idp/callback.
• IdP metadata XML: an XML document the IdP publishes, containing its Entity ID, sign-in endpoint, and signing certificate. Uploading it to the AxonOps console populates several configuration fields automatically.
• SP certificate and private key: an RSA key pair AxonOps uses to sign the SAML requests it sends to the IdP. Both are entered in the AxonOps console configuration; the key pair never needs to be uploaded to the IdP unless the IdP is configured to verify signed requests.
• Role claim: a value inside the assertion that the IdP populates with one or more AxonOps role strings, from which AxonOps Cloud derives the user's permissions. How the value is attached to the assertion is specific to each identity provider.

How AxonOps Cloud implements SAML

AxonOps Cloud is the SAML service provider. The Reply URL (ACS URL) that every IdP configuration must point to is https://<orgname>.axonops.cloud/login-idp/callback, where <orgname> is the AxonOps organisation name chosen when the AxonOps Cloud account was created.

An AxonOps user account is created automatically at the first successful SAML sign-in; accounts do not need to be created in advance.

AxonOps signs the SAML requests it sends to the IdP using an SP certificate and private key (RSA, PEM format). A self-signed certificate is acceptable.

Role mapping depends on the IdP sending AxonOps role names as role values inside the assertion. AxonOps Cloud reads those values and applies the corresponding AxonOps roles to the session; it does not derive roles from IdP group names directly. How a role value gets attached to the assertion (an app role, a custom user attribute, or another mechanism) is specific to each identity provider and is covered in the per-provider guides. A change to a user's role assignment in the IdP takes effect at the next SAML refresh; the refresh interval is normally controlled on the IdP side.

AxonOps Cloud rejects an assertion whose signature does not validate, or whose Entity ID does not match the configured values, and the login fails. A role value that does not match an AxonOps role name exactly (see the role reference below) grants no permissions.

SAML sign-in also depends on the IdP being reachable: while the IdP is unavailable, sign-in at https://<orgname>.axonops.cloud fails until it recovers. Sign-in at https://console.axonops.cloud does not involve the IdP and is unaffected.

After configuration, two login routes coexist: https://console.axonops.cloud (email and password, or Google or Microsoft account sign-in, unchanged) and https://<orgname>.axonops.cloud (SAML login through the IdP). The two routes hold separate accounts: a SAML account and a non-SAML account with the same email address are distinct accounts with their own permissions. The console.axonops.cloud route is also the recovery path: if a SAML configuration is wrong, log in there and correct it.

Dashboard URLs change once SAML is enabled

Once SAML is enabled for an organisation, the URLs of the AxonOps dashboard (the monitoring UI, as distinct from the console) change from dash.axonops.cloud to <orgname>.axonops.cloud. Existing bookmarks to dashboard pages stop working; normal operation is unaffected.

AxonOps role reference

The role values an IdP sends in the assertion must match AxonOps role names exactly. Role names are case-sensitive.

Global roles

Role	Access
superAdmin	Full access to all areas of the AxonOps console and dashboard.
admin	Similar to superAdmin, but cannot edit company properties in the console and cannot change some global settings in the dashboard.
dba	Read-only access to the main console; the same access level to dashboards as an admin user.
readonly	Read-only access to console and dashboard. Cannot edit any settings but can raise support tickets.

Cluster-type and per-cluster roles

Roles can be scoped to every cluster of a type, or to a single cluster:

• Cluster-type roles follow the format <orgname>/<clustertype>/<role>, for example <orgname>/cassandra/dba grants DBA access to all Cassandra clusters and <orgname>/kafka/readonly grants read-only access to all Kafka clusters.
• Per-cluster roles follow the format <orgname>/<clustertype>/<clustername>/<role>, for example <orgname>/cassandra/cluster1/readonly or <orgname>/kafka/kafka1/dba.

Only dba and readonly are supported at these levels; global-only roles such as superAdmin and admin do not have a cluster-type or per-cluster form.

Multiple roles are comma-separated in a single role value, and global and cluster-scoped roles combine. For example:

• readonly,<orgname>/cassandra/cluster1/dba grants read-only access to all clusters, plus DBA access to cluster1.
• <orgname>/cassandra/analytics/dba,<orgname>/cassandra/cluster2/readonly grants DBA access to the analytics cluster and read-only access to cluster2, with no global role.

Prerequisites

Before configuring SAML with any identity provider:

• SAML support enabled for the organisation.

• Administrative access to the identity provider.

• An RSA certificate and private key in PEM format. A self-signed pair is acceptable, for example generated with:

  openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -subj "/CN=axonops-saml" -keyout saml.key -out saml.crt

  Confirm the pair was produced with openssl x509 -in saml.crt -noout -subject -enddate, and protect saml.key as credential material.

• Superadmin access to the AxonOps console (https://console.axonops.cloud). This is the permission on an existing console account, distinct from the superAdmin SAML role value described above.

How-to guides

AxonOps Cloud supports Microsoft Entra ID, Okta, and JumpCloud as SAML identity providers. The how-to guides cover the provider-specific setup; a guide is available for Microsoft Entra ID.

This section covers AxonOps Cloud (SaaS). For SAML on self-hosted AxonOps deployments, contact AxonOps.