authentik and Elastic Cloud SAML integration

Test with a small pilot group of named users before you require SSO for the whole organization. Keep at least one local administrator account that can still sign in with a password, so you can recover if the SAML connection fails. Run each check below with a real test account, record the result, and only enforce SSO once every check passes. Confirm the exact enforcement behavior and the fallback path for your Elastic Cloud organization in the authentik integration guide and Elastic's documentation before you change anything in production.

Confirm that the domain you claimed in Elastic Cloud shows as verified and that the test users' email addresses use that exact domain. A user whose email domain does not match a claimed domain will not be routed through the SAML connection, so they will sign in another way or not at all. Check this before the pilot begins, because a domain that is still pending blocks the rest of the tests. Also confirm that your Enterprise subscription is active, since the authentik guide requires it for SAML SSO.

Sign in with one test account that should receive the Organization owner role and one that should receive a standard role, then check each account's role in the Elastic Cloud organization settings. Both checks matter. The first role mapping in authentik must include the Organization owner role, so the owner test confirms that mapping works, and the standard user test confirms that other mappings do not grant more access than intended. Record which authentik group produced each result so you can trace any mismatch.

Create a short matrix that lists each test user, their authentik groups, and the Elastic Cloud role they receive after signing in. Each row should match the mapping you designed, and any extra or missing role is a defect to fix before enforcement. Pay attention to users in more than one group, because their result depends on how the roles combine. Keep the groups attribute in the SAML assertion consistent with the group names used in the mappings, since a name mismatch is a common cause of users landing with no role.

Remove a test user from the relevant authentik group or deactivate the account, then try to sign in to Elastic Cloud with that user. Access should stop, and the user should no longer appear as an active member in the organization after the change is applied. Repeat the check for a user who had the owner role, because removing an owner needs its own review. Document how long the change took to take effect and whether existing sessions remained active, so your offboarding process reflects what actually happens.

Review the authentik event log for each test sign-in, looking for the authorization, the application access and any policy denials tied to the Elastic Cloud provider. Then review the Elastic Cloud side for the sign-in and role assignment events available to your organization. Compare the two timelines for the same test user, because mismatched timestamps or missing events usually point to a claim or routing problem. Forward logs to your central system if your audit process requires them, and confirm your enhanced audit logging needs against your authentik edition.

Expand only when every pilot check passes on repeated sign-ins, not just the first one. The main items are a verified claimed domain, correct owner and standard role assignment, group-to-role results that match the design, successful deprovisioning, and clean logs on both sides. Also confirm that the local administrator fallback still works and that the people who handle support know the recovery steps. Keep the test records as evidence for your change review, and schedule a short review after the first full week of enforcement.

DeployOpen can plan and carry out the pilot as part of a fixed-scope engagement, covering the authentik configuration, the Elastic Cloud settings, the test matrix and the evidence record. The scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that scope. Your team still owns the Elastic Cloud subscription, the claimed domain and the approval to enforce SSO. Your own administrators can also run these tests with the matrix described here if they have the access and time.

The cost comes from three separate places: the Elastic subscription, the authentik edition and the labor to configure both sides. SAML SSO on Elastic Cloud requires an Enterprise subscription, so the Elastic side is the largest recurring line item for most organizations. Elastic's Cloud Hosted pricing page lists starting prices of $99 per month for Standard, $114 for Gold, $131 for Platinum and $184 for Enterprise, based on a production configuration with 120 GB of storage across 2 zones, with instance usage priced on top. Those figures are starting points, so confirm the current numbers and your own deployment size with Elastic. On the authentik side, the SAML provider used for Elastic Cloud sits in the Enterprise edition, which the authentik pricing page lists at $5 per user per month billed annually plus $0.02 per external user per month. Labor is one-time for the initial build and recurring when roles or groups change. Ask any partner for a quote that separates these components and states which party pays for each.

Duration depends on how many roles and groups must map, how many domains need claiming, and whether your identity groups already exist in authentik. The technical configuration itself is short, but the timeline usually stretches around decisions: which authentik groups map to which Elastic roles, who approves the first owner mapping, and how domain verification is coordinated with your DNS team. Elastic's own subscription rules can also affect the schedule, because cross-cluster operations need the same subscription tier on every cluster involved. A fixed-scope engagement sets the timeline in writing before work starts, so ask for the dependencies to be listed as milestones rather than accepting a single estimate.

You need four things ready before configuration begins:

• An Elastic Cloud deployment on an Enterprise subscription, with an Organization owner account that can change SSO settings.
• A running authentik instance that you control, with an Enterprise license if you use the SAML provider for Elastic Cloud.
• At least one domain you can claim and verify in Elastic Cloud, with access to the DNS records needed for verification.
• A written group model in authentik that lists which groups map to which Elastic roles, including the Organization owner role required in the first role mapping.

Also confirm who in your organization approves changes to the groups attribute, since that attribute drives who receives which access in Elastic.

Yes, a team with administrative access to both Elastic Cloud and authentik can complete the configuration, provided it has someone who understands SAML assertions and role mapping. The risky part is not the clicks but the ordering: the first role mapping must include the Organization owner role, and a mistake there can lock out administrators from the Elastic organization. Teams that build internally should first test the flow with a non-production deployment and write down the group names and attribute values before touching production. A partner adds most value when the scope covers many roles, existing directory clean-up, or evidence that an auditor will later review.

Configuring SSO changes identity settings and role mappings, not the indices or documents stored in Elasticsearch. Backups remain a separate concern, and Elastic's documentation states that taking a snapshot is the only reliable and supported way to back up a cluster. Snapshots cannot be restored to an earlier Elasticsearch version, and restored indices must be compatible with the target cluster's version. Before changing identity settings, confirm that a recent snapshot exists and that your restore process has been tested. Do not treat the SSO change as a backup event, and take a snapshot before any upgrade that accompanies the integration.

Plan the groups attribute before you configure the connection, because it determines what Elastic Cloud does with each signed-in user. Define a small set of authentik groups, map each one to a single Elastic role, and keep the owner mapping limited to the people who must administer the organization. Name the groups clearly, avoid overlapping membership, and document who can add users to each group. Ask whether your Elastic role model needs custom roles, since adding roles later means revisiting the mappings and the groups attribute on both sides.

Confirm three things separately. First, the Elastic subscription tier that includes SAML SSO, since SAML requires an Enterprise subscription. Second, the authentik edition and license terms, because most code is under the MIT license while the enterprise directory is under its own license. Third, whether your Elastic plan includes features that depend on a specific tier, such as alerting based on anomaly detection, which needs Platinum or Enterprise. Elastic's subscriptions page notes that the Platinum tier is no longer available to new customers, so check the current tier list before committing. Ask your vendor or partner to confirm each point in writing.

Support splits between Elastic, authentik and whoever operates your identity configuration. Elastic supports its cloud service, authentik supports its software and the enterprise edition terms, and your team or a partner owns the mappings between them. After go-live, plan for recurring work when people change roles, when authentik or Elastic releases updates, and when you add domains. DeployOpen offers ongoing support and upgrades as retainers, and most engagements are fixed-scope with the post-launch responsibilities written into the agreement before work starts.