How many of you are tired of manually creating users within your Zabbix environment? Assigning the correct user groups, setting up permissions, and managing password changes every time a new person joins your company can be an exhausting and repetitive task. I think many of us feel this pain, but the good news is that there are systems designed to simplify all of this.

Today, we are going to dive into a fantastic solution: SAML 2.0. It is a powerful standard for exchanging authentication and authorization data between an Identity Provider (IdP)—which in our demo will be Okta, though it could easily be Microsoft Entra ID (formerly Azure AD)—and a Service Provider (SP), which is our Zabbix server.

Before we get our hands dirty with the configuration, let's break down the core concepts behind this integration.

How SAML 2.0 and Single Sign-On (SSO) Work in Zabbix

The concept is beautifully simple. When you navigate to your Zabbix web interface, instead of using the classic local login form, you will see a new option: Sign in with Single Sign-On (SAML).

When you click this button, here is what happens behind the scenes:

If the user does not already exist within Zabbix, a little bit of magic happens. Because we are going to enable Just-In-Time (JIT) provisioning, Zabbix will instantly recognize the authenticated user and automatically create their account on the fly, applying the exact permissions and roles we define.

Auto-Provisioning: JIT vs. SCIM

When automating user management, there are two main models you need to know about: JIT (Just-In-Time) and SCIM (System for Cross-domain Identity Management).

The Case for Just-In-Time (JIT) Provisioning

JIT is incredibly simple. Its biggest advantage is that it requires no complex firewall configurations or external inbound internet access. The user's browser acts as the transport layer. The only downside? Zabbix is only updated or informed of user changes (like a department change or a deactivation) during the actual login phase. If a user is disabled in Okta, Zabbix won't know until that user attempts to log in again (though they will be blocked from accessing the system).

The Dilemma with SCIM

SCIM, on the other hand, is an active synchronization system. Okta will constantly instruct the Zabbix server in real-time about who can access the system, creating or disabling users instantly in the background. This sounds perfect, right?

However, there is a catch. For SCIM to work, Okta (a cloud service) needs to communicate directly with your Zabbix server API. If your Zabbix instance is hosted on-premise and not exposed to the internet—which is common for security reasons—SCIM becomes a headache. You either have to open risky firewall ports or deploy an on-premise proxy agent. For many administrators, this extra infrastructure simply isn't worth the hassle. That is why I highly prefer and recommend JIT provisioning for its immediacy and ease of implementation.

Step 1: Configuring Okta as Your Identity Provider

Let's start by setting up Okta. If you don't have an account, register for an Okta Platform account and navigate to the Admin Console.

  1. Go to the Applications menu and click Create App Integration.
  2. Select SAML 2.0 and click Next.
  3. Give your app a recognizable name (e.g., Zabbix Test) and upload a logo if you wish.
  4. In the SAML settings, you need to define two critical URLs:
    • Single sign-on URL: Enter the path to your Zabbix SSO script. It should look like this: https://your-zabbix-domain.com/zabbix/index_sso.php?acs (Note: Remove the /zabbix/ path if your instance runs on the root domain).
    • Audience URI (SP Entity ID): This is the alias for your application. You can simply use zabbix.

Step 2: Mapping User Attributes in Okta

For JIT provisioning to work, Okta needs to send specific user data to Zabbix. In your Okta SAML settings, look for the Attribute Statements section. (You may need to click "Show legacy configuration" to see this).

Create the following mappings so Zabbix knows how to read the Okta data:

Next, configure the Group Attribute Statements. You can use a regular expression to map groups. For example, setting it to pull any group matching zabbix_* will automatically export groups like zabbix_admin and zabbix_user to Zabbix.

Once saved, assign your intended users to this application in Okta and ensure they are placed in the correct groups.

Step 3: Configuring Zabbix for SAML and JIT

Before leaving Okta, click on View SAML setup instructions. You will need three crucial pieces of information: the IdP Single Sign-On URL, the IdP Issuer, and the X.509 Certificate.

Now, log into your Zabbix interface as a Super Admin:

  1. Navigate to Users -> Authentication -> SAML settings.
  2. Enable SAML authentication and JIT provisioning.
  3. Fill in the fields using the data from Okta:
    • IdP entity ID: Paste the Okta IdP Issuer URL.
    • SSO service URL: Paste the Okta Single Sign-On URL.
    • SP entity ID: Enter zabbix (or whatever you set as the Audience URI in Okta).
    • Username attribute: Enter userEmail.
  4. Under the JIT provisioning section, map the attributes we defined earlier:
    • Group name attribute: groups
    • User name attribute: user_name
    • User last name attribute: user_lastname
  5. User Group Mapping: This is where the magic happens. Map the Okta group (e.g., zabbix_admin) to your internal Zabbix User Groups (e.g., Zabbix administrators) and assign the appropriate User Role (e.g., Super admin role).

Step 4: The Backend Certificate Configuration

There is one final, essential step required for Zabbix 7.0. You must manually place the Okta X.509 certificate on your Zabbix server.

  1. Copy the certificate text from Okta and save it as a file named idp.crt.
  2. Place this file in the Zabbix server directory: /usr/share/zabbix/conf/certs/idp.crt.
  3. Ensure the file has the correct permissions (e.g., chmod 644).
  4. Open your Zabbix frontend configuration file located at /etc/zabbix/web/zabbix.conf.php.
  5. Uncomment and configure the SSO settings array:
    $SSO['IDP_CERT'] = 'conf/certs/idp.crt';
    $SSO['SETTINGS'] =[ 'strict' => false, 'baseurl' => 'https://your-zabbix-domain.com/', 'use_proxy_headers' => true ];

Note: Enabling the $SSO['SETTINGS'] parameter is critical if you are using HTTPS, otherwise the integration will fail!

The Final Result

You don't even need to restart the Zabbix server. Log out, and you will see the new SAML login option. Click it, authenticate via Okta, and boom—you are inside Zabbix! If you check your user profile, you will notice that your account was automatically provisioned by the IdP, complete with the correct administrative rights and group memberships.

Integrating Zabbix into your company's existing SSO ecosystem (whether Okta or Microsoft Entra ID) is a massive time-saver. It reduces administrative overhead, ensures tighter security by centralizing password management, and makes onboarding new engineers completely frictionless.

What do you think of this solution? Do you prefer the simplicity of Just-In-Time provisioning, or do you find SCIM worth the extra infrastructure effort? I'd love to hear your thoughts and experiences.

If you found this guide helpful, please let me know in the comments! For more tutorials, deeper dives into monitoring, and tech discussions, make sure to connect with me:

See you next week!
— Dimitri Bellini