authentik and Zabbix SAML integration

How to set up Zabbix SAML integration with authentik

This section is for the team that runs Zabbix monitoring and wants staff to sign in through the organization's central identity provider instead of local Zabbix accounts. It answers two questions: what authentik provides in this setup, and what work sits between a running authentik and a working Zabbix frontend. In this integration authentik acts as the SAML identity provider, and Zabbix acts as the service provider. The integration follows the Zabbix guide in the authentik integrations catalog, so the build is configuration and verification rather than custom development.

Most of the effort falls into four areas. The first is prerequisites on the Zabbix web host, where the php-openssl extension must be available to PHP so that SAML authentication can run. The second is certificate placement: the authentik signing certificate must be copied into the Zabbix frontend conf/certs directory so Zabbix can validate assertions. The third is the SAML provider and application in authentik, with entity IDs, assertion consumer URLs and the signing setup matched exactly to what the Zabbix frontend expects. The fourth is provisioning and role mapping, which decides which authentik groups receive which Zabbix user roles. Confirm the exact settings and file paths against the guide for your Zabbix version before you change production.

Plan the role mapping before the first live login. Decide which authentik groups map to Zabbix user types and which group keeps a local Zabbix administrator account for recovery, because a SAML misconfiguration can lock out every frontend user. Test the path in a non-production frontend first, with one administrative test account and one standard user. Check the Zabbix authentication documentation to confirm how SAML provisioning and the local fallback behave in your release, and record the result so the same checks can be repeated after each Zabbix or authentik upgrade.

What your Zabbix and authentik environment needs before SAML

SAML sign-in to the Zabbix frontend depends on decisions made before any configuration starts: which Zabbix line you run, which authentik release line you run, and what the frontend nodes and network can support. Settle these cards first so the SAML build does not stall on a version or certificate problem.

Choose your Zabbix line

Confirm which Zabbix version your frontend runs and whether it sits on a supported line. Zabbix 7.4 is a standard release with full support until Zabbix 8.0 LTS and limited support until Q1 2027. Zabbix 7.0 LTS has full support until 30 June 2027. Zabbix 6.0 LTS limited support ends on 28 February 2027, so a 6.0 deployment should be upgraded before you invest in a SAML build that will need repeating on the new version.

Confirm the authentik release line

Check that your authentik server and worker run a release line that receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported lines, and security releases are announced at least 24 hours in advance. Record the exact version you run, because the SAML provider settings and the signing certificate workflow depend on it, and plan to move to a supported line before go-live.

Verify php-openssl on every frontend node

Zabbix needs the php-openssl extension for SAML authentication, and it must be loaded on every frontend node behind your load balancer, not only the one you test on. Check the PHP runtime each node actually uses, including the web server's PHP-FPM pool if you run one. A node missing the extension will fail sign-in intermittently, which is hard to diagnose from user reports alone.

Grant write access to the certs directory

The Zabbix frontend must read the authentik signing certificate from its conf/certs directory, so the web server user needs access to place and read that file. Decide who owns the certificate file, how it is replaced when authentik rotates its signing key, and whether the change goes through your configuration management. Treat the directory as part of the frontend configuration, and record it in your change process.

Synchronize time across the sign-in path

SAML assertions carry validity windows, so the browser, the Zabbix frontend nodes and the authentik server need reliably synchronized clocks. Confirm that each host uses the same time source and that no proxy or load balancer adds delay that narrows the validity window. Clock drift often appears as sign-in failures that look like certificate or configuration errors, so check time first when a login is rejected.

Prepare an authentik administrator path

Before enabling SAML, confirm you hold an authentik administrator account that can create the provider, application and group bindings, and keep a local Zabbix Super Admin available for recovery. Decide who may make changes in authentik and who approves them. A break-glass path matters because a misconfigured SAML setting can block every interactive Zabbix login, including yours.

Configuring authentik and the Zabbix frontend in order

This sequence sets up SAML sign-in from authentik to the Zabbix web frontend, with the signing certificate and PHP prerequisites in place, and confirms that one non-administrative user can sign in and land in Zabbix with the expected account.

Create the SAML provider and application
In the authentik admin interface, create a SAML provider and an application that points to your Zabbix frontend. Set the ACS URL and audience to match the Zabbix frontend address you will use in production, and confirm which signing settings the provider uses. Keep a note of the entity ID and the SSO endpoint URLs authentik generates, because Zabbix needs them in a later step. Check that the application appears in the user-facing library and that the provider shows the endpoints you recorded. Confirm the exact field names and settings against the authentik Zabbix guide before you start, since the guide is the reference for this integration.
Export the authentik signing certificate
From the SAML provider settings in authentik, export the signing certificate in the format the guide specifies. Save it to a staging location on your administration workstation, not directly on a frontend. Open the file in a text editor and confirm it begins and ends with the standard certificate markers and contains no extra lines from copy and paste. Record the certificate's file name, because you will reference it in the Zabbix configuration. The check is a clean certificate file that you can read locally without errors.
Install php-openssl on each frontend
On every Zabbix frontend host, install or enable the php-openssl extension for the PHP version your web server uses. Run the PHP module listing on each host and confirm that openssl appears. Restart the web server or PHP-FPM service so the change takes effect. Do this on every frontend behind your load balancer, because a node that lacks the module will fail SAML sign-in intermittently. The check is that the module is listed on all frontend hosts and the web server restarts cleanly.
Place the certificate in the frontend certs directory
Copy the authentik signing certificate into the frontend conf/certs directory on each Zabbix frontend host. Set ownership and permissions so the web server user can read the file, but restrict write access to administrators. Repeat the copy on every frontend so all nodes present the same signing material. Confirm the file is readable by the web server user by running a read test as that account, for example with a command that opens the file as that user. A readable file that matches the exported certificate on every host closes this step.
Enter the SAML values in Zabbix
In the Zabbix frontend, open the authentication settings and enable SAML as the authentication method. Enter the entity ID, the SSO endpoint, and the certificate file name exactly as they appear in authentik, and set the username and group attribute names to match the claims authentik sends. Leave local administrator access enabled until the test in the final step succeeds, so you keep a way back in if the configuration is wrong. Save the settings and confirm the form stores the values without validation errors. Refer to the Zabbix authentication documentation for the current field names.
Map provisioned groups to Zabbix user roles
Decide which authentik groups correspond to Zabbix user groups and roles, and configure the group mapping in the Zabbix SAML settings so that signed-in users receive the intended role. Use a small, written list of groups for the pilot, and record which Zabbix user group each one maps to. Verify the mapping by checking the group membership of the test account in authentik before signing in. This step produces the access model the test account will exercise, so review it with the team that owns Zabbix permissions.
Test with one non-admin account
Sign in to the Zabbix frontend using a non-administrative test account from a private browser session. Confirm that authentik authenticates the user, that the browser returns to Zabbix, and that the user appears in the Zabbix user list with the role the group mapping should assign. Check that the user sees only the host groups their role allows. Only after this test passes on every frontend, decide whether to restrict local login and document the break-glass procedure for your team.

Where the signing certificate goes on each Zabbix install type

On a host where the Zabbix frontend was installed from distribution packages, the frontend sits in a web root managed by the package manager, and the web server runs PHP under its own service account. Start by identifying the exact frontend directory and the PHP version the web server loads, because the conf/certs directory sits inside that tree and package upgrades can replace files around it.

Enable the extension first: Confirm the php-openssl module is loaded in the PHP version the web server uses, not only the command-line PHP, then restart the web service.
Locate conf/certs: Find the conf/certs directory inside the frontend tree and place the authentik signing certificate there under a file name you record in the SAML settings.
Match ownership to the web user: Make the certificate readable by the account PHP runs as, and keep it unwritable by other local users.
Plan for package updates: Package upgrades may overwrite or relocate frontend files, so confirm the certificate survives an upgrade on a test host first.
Confirm paths for your version: Check the exact directory against your installed Zabbix version and the authentik Zabbix guide before you copy anything.

Before you finish, load the SAML sign-in page on the same host and check the web server log for permission errors when the certificate is read.

Mapping authentik groups and attributes to Zabbix user roles

This table maps each authentik group or attribute to the Zabbix user group, user role and access consequence it should produce. Read the Zabbix column as the target configuration and the confirm column as the item to check against the Zabbix authentication documentation for your exact version before you go live. The main takeaway is that role and host-group scope are set in Zabbix, so authentik should only supply a stable group signal that Zabbix can match.

Authentik source	Zabbix target	Access consequence	Confirm before go-live
Admin group (for example, a group named zabbix-admins)	Zabbix user group with a role that grants full administration rights, mapped through the SAML group attribute	Members can change configuration, users and templates; keep this group small and reviewed	Yes, confirm the role type that grants full access and the exact SAML group attribute name in the Zabbix authentication documentation for your version
Read-only operators group (for example, zabbix-readonly)	Zabbix user group with a read-only role and no configuration rights	Members view dashboards, problems and host data without changing settings	Yes, confirm which default roles exist in your version and that read-only access excludes configuration menus
Host-group scoping group (for example, zabbix-network-ops)	Zabbix user group with permissions limited to the named host groups	Members see and act only on hosts in the assigned host groups	Yes, confirm host-group permission rules and how inherited permissions interact with the role
Fallback for users with no matching group	Default or no-access user group, with JIT provisioning set to create users only when a group matches	Users without a mapped group either receive minimal access or are denied sign-in	Yes, confirm the behavior of unmatched SAML users and whether provisioning creates accounts without groups in your version
Email attribute from the authentik user record	Zabbix user media (email) used for problem notifications	Notifications reach the address supplied by the identity provider	Yes, confirm the SAML attribute mapping for the username and media fields in your version
Multiple group memberships	Several Zabbix user groups assigned to one account	Effective access is the combined permissions, which can widen access unexpectedly	Yes, confirm how overlapping user groups combine and test with an account holding two groups

Provisioning users and keeping local admin access

Decide how Zabbix creates accounts before the first SAML sign-in, because that choice determines who can reach the frontend and with which role. Check the Zabbix authentication documentation for your version to confirm whether SAML sign-in creates a user on first login, which role and group settings apply to the new account, and what happens when a local Zabbix account already uses the same username as the authentik user. The outcomes matter: an existing local account could be linked to the SSO identity, updated with new settings, or left unchanged while the SSO login is refused. Test each case with a dummy authentik user on a non-production frontend and write down the result for each Zabbix version you run.

Keep at least one local Zabbix administrator for recovery. This account should be a named super administrator with a strong password stored in your secrets manager, and its login should be tested before go-live and after every Zabbix or authentik upgrade. Its purpose is to restore access when authentik, the SAML signing certificate in the frontend conf/certs directory, or the network path between the two is broken. Do not use it for daily administration, and do not let it depend on group mapping, so a change in authentik cannot remove it. Record who may use it, under which conditions, and how the use is reviewed afterward.

Deprovisioning does not happen automatically in the sense many teams expect. Disabling or deleting a user in authentik stops new SAML sign-ins, but an existing Zabbix account stays in the database with its role and its history. Treat offboarding as two steps: disable the authentik user, then disable or remove the matching Zabbix user, and assign that work to a named owner. Schedule a recurring review that compares active Zabbix users with active authentik users, especially for accounts that hold administrative roles. Confirm with your Zabbix version whether the frontend re-evaluates group membership on each login, because that behavior affects how quickly a role change takes effect.

Hardening the Zabbix SAML sign-in path

SAML moves the sign-in decision to authentik, but the Zabbix frontend still holds sessions, local accounts and role assignments. The cards below cover the controls that keep that path narrow: transport, certificates, the local login fallback, MFA in authentik, role scope and failure logging. Check each one after the first working SAML login and again after every authentik or Zabbix upgrade.

HTTPS only on the frontend

The SAML exchange sends signed assertions through the browser, and the Zabbix session cookie is only as safe as the connection that carries it. Serve the Zabbix web frontend over HTTPS only, redirect plain HTTP, and confirm that the ACS and redirect URLs registered in authentik use the same HTTPS hostname. A mismatch between the hostname in the SAML configuration and the one users browse to is a common cause of failed sign-ins, and it is also a sign that a second, unintended entry point exists. Check the certificate chain from a machine outside your internal network.

Signing certificate rotation tracking

The authentik signing certificate placed in the Zabbix frontend conf/certs directory must match the key authentik uses to sign assertions. When authentik rotates or replaces that certificate, Zabbix will reject every SAML login until the copy is updated. Record the certificate's expiry date in your change calendar, assign an owner, and test a rotation in a non-production Zabbix instance first. Keep file permissions tight so that only the web server account can read the certificate material.

Named break-glass local accounts

Zabbix can keep local password logins available next to SAML, so a directory or authentik outage does not lock out operators. Treat that path as an emergency door: keep a small, named set of local Zabbix Super admin accounts, store their passwords and any second factor under dual control, and disable them for daily use. Review who holds them each time staff change. Confirm in your own environment how the frontend authentication settings handle these accounts, since the setup depends on the Zabbix version you run.

MFA enforced in authentik

Zabbix does not decide whether a user has passed a second factor when SAML is in use. That decision belongs to the authentication flow in authentik, so the Zabbix application must sit behind a flow or policy that requires MFA for every user who can reach it. Confirm that the authorization policy bound to the Zabbix provider applies to all groups that map to Zabbix roles, and test with a user who has no enrolled factor to see that access is refused. Review the factor enrollment policy so users cannot skip enrollment.

Least-privilege role mapping

Map authentik groups to the lowest Zabbix user role that does the job, and avoid giving the Super admin role to any group that a broad population can join. Keep one authentik group per Zabbix role, and document which host groups each role can read or change. Review the mapping after each organizational change, because a stale group membership keeps working until someone removes it. Test the mapping with one account per role before you open access to the wider team.

Logging of SAML failures

Failed assertions, expired certificates and rejected logins are the first signs that the SAML path is broken or under attack, and they are easy to miss when only successful logins are watched. Enable authentik event logging for the Zabbix provider and forward those events to your central log system. On the Zabbix side, review the frontend and web server logs for repeated failed sign-ins and for local login attempts on break-glass accounts. Set an alert for any local login to a Super admin account, and confirm the alert fires in a test.

Testing the sign-in before users depend on it

The first step is to run a fixed set of sign-in tests against the Zabbix frontend before any operator or monitoring user is told to rely on SAML. Test with a non-admin user who holds a mapped group that gives read-only or limited access, and an admin user whose group maps to a Zabbix role with write and configuration rights. Then test a user with no mapped group. Confirm that this account either lands on a clear denial or receives the default role you intended, and that it never inherits access by accident. Add a disabled authentik user and confirm that Zabbix refuses the login even if an earlier session still exists. Each result should be recorded with the user, the group claim seen in the assertion and the Zabbix role applied, so a later change can be compared against a known baseline.

Certificate handling needs its own tests. Deliberately present an expired or wrong certificate on a non-production frontend, or swap the signing certificate in the conf/certs directory for a test copy, and confirm that sign-in fails with an error your team can recognize and that the Zabbix log points to the cause. Then run a forced logout and re-login for each test user, because a successful first login does not prove that session handling and group re-evaluation work after the browser session ends. Confirm the exact certificate expiry date in authentik and set a reminder well before it, since the test plan only helps if the signing certificate is current.

Repeat this full test set after each Zabbix minor update and after each authentik upgrade, and confirm the current support status of your Zabbix version in the Zabbix life cycle and release policy before scheduling the window. High availability of the Zabbix server does not replace this work. The server cluster fails over monitoring duties between server nodes, but each frontend node serves its own login path, so test sign-in on every frontend node behind your load balancer, not only on the one that answers first. Ask your implementation partner to include these tests, with recorded results, in the acceptance criteria for the project.

Common SAML failures in Zabbix and their causes

This table lists the failures teams most often hit when enabling SAML sign-in to the Zabbix frontend with authentik, with the likely cause, the check to run and the direction of the fix for each. Work through it in order, because a missing PHP extension or certificate problem will hide the later SAML checks.

Symptom	Likely cause	Check and fix direction
SAML option missing from the frontend	Zabbix has not loaded SAML support, usually because the php-openssl extension is absent or the PHP build used by the web server differs from the CLI build	Confirm php-openssl is enabled for the PHP version serving the frontend, then restart the web server. Check the authentication settings page again after the restart.
PHP or module error on the login page	php-openssl is missing or disabled, or the web server runs a different PHP configuration than expected	Read the frontend and PHP error logs for openssl-related messages. Install or enable the extension for the active PHP version, then retest. Confirm the exact requirement in the Zabbix authentication documentation.
Certificate not readable by the web server	The authentik signing certificate is outside the frontend conf/certs directory, or file ownership and permissions block the web server user	Place the certificate where the integration guide expects it under the frontend conf/certs directory. Check that the web server user can read the file and that the path matches the configured value.
Entity or endpoint mismatch at sign-in	The entity ID, ACS URL or metadata values in Zabbix do not match the SAML provider settings in authentik, often after a hostname or scheme change	Compare each value on both sides character by character, including https scheme and trailing slashes. Correct the authentik provider or the Zabbix setting, then test a fresh sign-in.
User signs in but lands with the wrong role	Group or attribute mapping does not match the group name sent in the assertion, or the user is provisioned with a default role	Inspect the SAML attributes sent for a test user and compare them with the mapping rules in Zabbix. Adjust the group names or the mapping, then sign in again. Confirm the mapping behavior in the vendor documentation.
Assertion rejected because of time skew	Clock drift between the Zabbix host, the authentik servers and the identity clients makes assertion validity windows fail	Check time synchronization on all systems with the same NTP source. Correct drift before changing SAML settings, since clock errors look like configuration errors.
Administrator locked out after enabling SAML	SAML was enforced for all users, or the only local administrator account was not kept as a fallback	Keep a local Zabbix administrator account enabled and tested before changing the default authentication method. If locked out, restore local authentication through the database or configuration path described in the vendor documentation, then fix the SAML settings.

What a Zabbix SAML integration costs and takes

What drives the cost of a Zabbix SAML integration with authentik?

The main cost drivers are scope and the number of moving parts, not the SAML protocol itself. Count the Zabbix frontends that will accept SAML sign-in, the identity groups that must map to Zabbix user roles, and the existing local accounts that need a migration path. Add the change control and test scope your organization requires, such as a staging Zabbix instance, a documented rollback and sign-off from the monitoring owners. Each item adds configuration, testing and review time. A written scope that lists these counts is what allows a fixed quote, and a quote should show who does each task and what is handed over at the end.

Which parts of a Zabbix SAML integration are one-time and which recur?

The initial build is one-time: the SAML provider and application in authentik, the Zabbix frontend settings, certificate placement, group mapping and testing. Recurring work follows from those choices. Signing certificates need renewal before they expire, so someone must own that date. Zabbix and authentik both publish new releases, and each upgrade can change the frontend or the SAML behavior, so each upgrade needs a test pass. Role mappings also need periodic review as teams change. Ask any partner to state which of these tasks are included in the initial scope and which would be ongoing support, since ongoing support is available as a retainer.

Can our team set up Zabbix SAML with authentik using only the vendor guide?

A team with working knowledge of both products can often follow the authentik integration guide, but the guide covers the core steps rather than your environment. The guide calls for php-openssl on the Zabbix frontend and access to the frontend conf/certs directory for the authentik signing certificate. Your team still has to decide how group claims map to Zabbix user roles, how existing local accounts are handled, how the frontend is reached through your reverse proxy, and how you will test sign-in and recover if SSO fails. If your administrators have not run a SAML setup before, or the frontend is business-critical, a short review of the design before go-live reduces the risk of lockout.

What does our team need to provide for the integration work?

Four roles and inputs are needed. First, an authentik administrator who can create the SAML provider, application, and group bindings and who can export or rotate the signing certificate. Second, a Zabbix administrator who can change the frontend configuration, place certificate files and restart the web service during the window. Third, a test group of real users with different roles, so mapping errors surface before everyone is moved. Fourth, a maintenance window that covers the cutover and the rollback plan. Confirm whether the people in these roles are internal staff or whether a partner will work alongside them, and agree on who holds production access during the work.

How do existing Zabbix local accounts affect the migration effort?

Existing local accounts add work because each one needs a decision: keep it as a fallback administrator, link it to the SAML identity, or retire it after users confirm sign-in. Keep at least one local administrator for recovery in case authentik or the certificate is unavailable, and document how it is protected. The number of accounts and the number of roles they hold determine how much review is needed before cutover. Check how Zabbix authentication settings apply to each user type in the Zabbix authentication documentation before you change the default, so that you do not lock out the only administrators.

How much does Zabbix support cost compared with a SAML integration project?

These are separate costs and should be compared separately. Zabbix states that its open source software has no license fee, no device limits and no feature gates, so the Zabbix server itself carries no license charge. Paid technical support from Zabbix comes in Silver, Gold, Platinum, Enterprise and Global tiers, with response times and coverage that differ by tier, such as 8x5 coverage with a 1 day response for Silver and 24x7 coverage with a 1 hour response for Global. On the authentik side, the open source edition is free, while the pricing page lists enterprise editions with per-user terms. Use the authentik pricing page and the Zabbix support page to build your own comparison, and note that the SAML integration itself does not require an enterprise edition of authentik.

How does a quote follow from a written scope for this integration?

DeployOpen does not publish a price list. A quote follows from a written scope that is agreed before work starts. The scope should state the Zabbix version and frontend count, the authentik version and provider type, the identity groups and roles to map, the handling of local accounts, the test plan and rollback steps, the handover documents and the maintenance window. Engagements are typically fixed-scope, so changes to the scope are handled as written amendments. Ask for the quote to list each deliverable, the responsibilities of your team and the partner, and what is excluded, so you can compare it with the internal effort estimated from the same scope.

What should we check in our environment before asking for a quote?

Collect the facts that change the scope before you contact a partner. Confirm the Zabbix version and whether it is a supported release. The life cycle policy lists 7.0 LTS with full support until 30 June 2027 and 7.4 with full support until Zabbix 8.0 LTS, so an older version may need an upgrade first. Confirm that php-openssl is available on the frontend host, that you can reach the conf/certs directory, and how the frontend is served behind your proxy. List the authentik instance and its version, and whether it is already used for other applications. Finally, record the identity groups, the number of users per role and any local accounts, because these drive the mapping work.

How DeployOpen scopes and delivers the Zabbix SAML integration

DeployOpen plans and implements the authentik and Zabbix SAML integration inside your own infrastructure, as a fixed-scope engagement agreed in writing before work starts. The work covers the authentik SAML provider, the Zabbix frontend configuration, certificate placement, group mapping and verification, followed by documented handover and optional ongoing support.

How we scope

Written scope covers the authentik SAML provider, application and signing certificate settings for your Zabbix frontend.
We confirm your Zabbix version, its support status and the PHP build, including php-openssl availability, before any changes.
We agree in writing which authentik groups map to which Zabbix user roles, and who approves that mapping.
Scope states which break-glass local Zabbix accounts remain available if SAML sign-in fails.

How we build

We prepare a test Zabbix frontend and authentik instance that mirror your production configuration where possible.
We install and verify the signing certificate in the frontend conf/certs directory with the correct file permissions.
We configure user provisioning and group mapping in a staged order, testing each role against sample test accounts.
We record configuration values and the reasons behind each mapping decision as the build progresses.

How we hand over

Deliverables include the configured SAML settings, the group-to-role mapping table and the certificate renewal steps.
We document the test cases used to confirm sign-in, provisioning and role assignment for each group.
Your team receives a runbook covering failed sign-ins, certificate expiry checks and rollback to local authentication.
Handover includes a walkthrough with the engineers who will operate the integration after go-live.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer support can cover re-testing after Zabbix frontend upgrades and authentik version changes.
Ask the support scope to confirm which authentik and Zabbix versions are covered and the response expectations in writing.
Confirm with your team who approves changes to group mappings once the integration is in production.