Managing user access across multiple security platforms quickly becomes difficult as organizations grow. Security teams often need to maintain separate accounts for SIEM platforms, endpoint security tools, cloud services, and internal applications. This fragmented authentication model increases administrative overhead, creates inconsistent security policies, and raises the risk of compromised credentials. Configuring Wazuh SSO (Single Sign-On) solves these challenges by allowing users to authenticate through a centralized identity provider (IdP) instead of maintaining separate Wazuh credentials.

Administrators can integrate enterprise identity platforms such as Microsoft Entra ID (formerly Azure Active Directory), Okta, Keycloak, or other SAML and OpenID Connect (OIDC) providers to provide seamless, secure access to the Wazuh Dashboard.

Beyond convenience, SSO strengthens security by enforcing centralized password policies, multi-factor authentication (MFA), conditional access rules, and automated user lifecycle management.

Instead of manually creating and deleting dashboard accounts, administrators can manage authentication entirely from their organization’s identity provider while using Wazuh’s Role-Based Access Control (RBAC) to determine what authenticated users are allowed to access.

In this guide, you’ll learn how Wazuh SSO works, how authentication flows through OpenSearch Security, how to configure SAML or OpenID Connect authentication, map users to Wazuh roles, troubleshoot common issues, and follow security best practices for production deployments.

What Is Wazuh SSO?

Definition of Single Sign-On (SSO)

Single Sign-On (SSO) is an authentication mechanism that allows users to log in once with a trusted identity provider and gain access to multiple applications without entering separate usernames and passwords for each service.

Rather than storing user credentials locally within every application, authentication is delegated to a centralized identity platform that verifies the user’s identity before granting access.

Common enterprise identity providers include:

• Microsoft Entra ID
• Okta
• Keycloak
• Ping Identity
• Google Workspace
• Auth0
• Active Directory Federation Services (AD FS)

The two most common protocols used for modern SSO implementations are:

• OpenID Connect (OIDC) — built on OAuth 2.0 and commonly used for cloud-native applications.
• SAML 2.0 — XML-based authentication widely used by enterprise identity systems.

Both protocols allow authentication to occur without exposing passwords directly to the application.

How SSO Works in Wazuh

Wazuh itself does not authenticate users directly. Instead, authentication is handled by the OpenSearch Security plugin that protects the Wazuh Dashboard.

A typical login flow works like this:

1. A user opens the Wazuh Dashboard.
2. The dashboard redirects the user to the configured identity provider.
3. The user authenticates using corporate credentials.
4. Multi-factor authentication (if enabled) is completed.
5. The identity provider issues a signed authentication token or assertion.
6. OpenSearch validates the token.
7. User attributes and group memberships are extracted.
8. Wazuh RBAC maps the user to one or more security roles.
9. The dashboard loads with permissions appropriate for that user.

Since authentication occurs outside Wazuh, organizations can enforce a consistent authentication policy across their entire infrastructure.

Supported Authentication Methods

Because Wazuh relies on the OpenSearch Security plugin, it supports several authentication mechanisms.

The most common include:

• OpenID Connect (OIDC)
• SAML 2.0
• LDAP authentication
• Active Directory
• Kerberos
• JSON Web Token (JWT)
• Basic internal authentication (local users)
• Proxy authentication

Most enterprise deployments choose either OIDC or SAML because they integrate easily with modern identity providers while supporting advanced security features such as MFA and conditional access.

Organizations already using Active Directory often combine LDAP with SSO to centralize both authentication and authorization.

Related Guide: How to Configure Wazuh LDAP Authentication

Benefits of Centralized Authentication

Centralized authentication provides advantages far beyond reducing the number of passwords users must remember.

Key benefits include:

• One identity across multiple security platforms
• Central password policy enforcement
• Multi-factor authentication support
• Conditional access policies
• Automatic account provisioning
• Immediate account revocation
• Reduced administrative effort
• Consistent security controls
• Lower risk of password reuse
• Improved visibility into authentication events

According to guidance from the Cybersecurity and Infrastructure Security Agency, organizations should implement centralized identity management and strong authentication controls, including MFA, to reduce credential-based attacks.

Common Enterprise Use Cases

SSO becomes especially valuable in larger environments where multiple administrators, analysts, and security teams access Wazuh daily.

Common deployments include:

• Security Operations Centers (SOCs)
• Managed Security Service Providers (MSSPs)
• Government agencies
• Healthcare organizations
• Financial institutions
• Universities
• Large enterprises with multiple business units
• Multi-tenant Wazuh environments

For example, an MSSP may authenticate every analyst through Microsoft Entra ID while using RBAC to ensure each analyst only accesses the customer environments assigned to them.

Related Guide: How to Set Up Wazuh Multi-Tenancy

How Wazuh Authentication Works

Understanding the authentication architecture helps simplify SSO configuration and troubleshooting.

Wazuh Dashboard Authentication

The Wazuh Dashboard serves as the primary web interface used by analysts and administrators.

Unlike standalone web applications, the dashboard relies on the underlying OpenSearch Security plugin to authenticate users.

The dashboard simply redirects authentication requests and displays the interface after authentication succeeds.

This separation allows administrators to replace local authentication with enterprise SSO without modifying Wazuh itself.

OpenSearch Security Plugin

The OpenSearch Security plugin is responsible for:

• Authenticating users
• Validating SAML assertions
• Validating OIDC tokens
• Managing authentication domains
• Mapping backend roles
• Enforcing permissions
• Applying RBAC policies

It acts as the bridge between Wazuh and the organization’s identity provider.

Authentication configuration is typically stored within the OpenSearch Security configuration, where administrators define:

• Authentication backend
• Identity provider metadata
• Certificates
• Token validation rules
• Backend role mappings
• Session configuration

Identity Providers (IdPs)

An Identity Provider (IdP) is the trusted system responsible for verifying a user’s identity.

Popular providers include:

• Microsoft Entra ID
• Okta
• Keycloak
• Google Workspace
• Auth0
• Ping Identity
• Active Directory Federation Services

Rather than maintaining users inside Wazuh, administrators synchronize identities through the IdP.

Many organizations already use the same provider for:

• Microsoft 365
• VPN access
• Cloud platforms
• Git repositories
• Internal web portals
• HR applications

Adding Wazuh to the same authentication ecosystem creates a consistent login experience across the organization.

Authentication Flow

The authentication process typically follows these stages:

1. The user requests the Wazuh Dashboard.
2. OpenSearch detects that SSO authentication is required.
3. The browser redirects to the identity provider.
4. The user authenticates.
5. MFA is completed if required.
6. The IdP generates a signed SAML assertion or OIDC token.
7. OpenSearch validates signatures and certificates.
8. User attributes and group claims are extracted.
9. Backend roles are mapped.
10. Wazuh authorizes dashboard access based on RBAC permissions.

At no point does Wazuh need to store or verify the user’s password.

Role-Based Authorization After Login

Authentication only proves who a user is.

Authorization determines what they can do.

After a successful login, Wazuh evaluates role mappings configured within OpenSearch Security.

Typical permissions include:

• Read-only analyst
• Security analyst
• SOC administrator
• Platform administrator
• Auditor
• Compliance officer
• Tenant administrator

Users can also inherit permissions from directory groups, making role management significantly easier in large organizations.

For example:

• Members of SOC-Admins receive administrative privileges.
• Members of Tier-1 Analysts receive read-only investigation permissions.
• Members of Compliance receive audit-only access.

Related Guide: Troubleshooting Wazuh RBAC

Benefits of Configuring Wazuh SSO

Implementing SSO provides operational, administrative, and security improvements that become increasingly valuable as deployments grow.

Centralized User Management

Administrators no longer need to create local dashboard accounts for every employee.

Instead, they manage identities entirely within their existing identity provider.

Benefits include:

• One source of truth
• Consistent permissions
• Automatic group synchronization
• Fewer administrative tasks
• Reduced configuration errors

This approach is especially useful in organizations with hundreds or thousands of users.

Improved Security

Centralized authentication strengthens security by enabling organization-wide identity controls.

These include:

• Multi-factor authentication
• Conditional access
• Password complexity policies
• Account lockout policies
• Risk-based authentication
• Device compliance checks
• Identity protection policies

Security experts, including the National Institute of Standards and Technology, recommend centralized identity management and phishing-resistant MFA as key components of modern authentication strategies.

Better User Experience

Analysts access Wazuh using the same credentials they already use throughout the organization.

Advantages include:

• Faster login
• Fewer password prompts
• Seamless application switching
• Consistent authentication experience
• Reduced support requests

A smoother login experience often leads to higher adoption and fewer authentication-related help desk tickets.

Reduced Password Fatigue

Password fatigue occurs when users manage numerous credentials across different systems.

This often leads to poor security practices such as:

• Password reuse
• Weak passwords
• Writing passwords down
• Storing passwords in unsecured locations

SSO minimizes these risks by reducing the number of credentials users must actively manage while allowing organizations to enforce stronger authentication policies.

Simplified Compliance and Auditing

Many compliance frameworks require organizations to demonstrate controlled access to sensitive systems.

SSO helps satisfy these requirements by centralizing:

• Authentication logs
• User lifecycle events
• MFA enforcement
• Account disablement
• Access reviews
• Login history
• Identity verification

Auditors can review authentication activity from a single identity platform instead of collecting logs from multiple applications.

For additional visibility into authentication activity within Wazuh, you can also configure centralized logging and monitor dashboard access events.

Related Guide: How to Configure Wazuh as a Centralized Syslog Server

Easier Onboarding and Offboarding

Employee lifecycle management becomes much simpler with centralized identities.

When a new employee joins:

• Create the account in the identity provider.
• Add the appropriate security group.
• Wazuh permissions are assigned automatically through role mappings.

When an employee leaves:

• Disable the identity provider account.
• Access to Wazuh is revoked immediately.
• No manual dashboard cleanup is required.

This automation reduces the risk of orphaned accounts and ensures access changes are applied consistently across the organization.

Prerequisites

Before configuring Wazuh SSO, verify that your environment meets the necessary requirements.

Most authentication issues stem from missing prerequisites rather than incorrect SAML or OpenID Connect settings.

Preparing your environment beforehand minimizes downtime and makes troubleshooting significantly easier.

Working Wazuh Deployment

Ensure your Wazuh deployment is fully operational before introducing SSO.

Verify that:

• Wazuh Manager is running
• Wazuh Dashboard is accessible
• OpenSearch Indexer is healthy
• Existing local authentication works correctly
• RBAC is functioning as expected
• Dashboard users can successfully log in

If your deployment already has authentication or dashboard issues, resolve those first before implementing SSO.

Helpful checks include:

systemctl status wazuh-manager
systemctl status wazuh-dashboard
systemctl status wazuh-indexer

You should also verify cluster health if you’re running a multi-node deployment.

Related Guides:

• How to Set Up a Multi-Node Wazuh Cluster
• How to Fix Wazuh Dashboard Server Is Not Ready Yet (Step-by-Step)

Administrative Access

You’ll need administrative privileges on every component involved in the authentication process.

Typically this includes:

• Root or sudo access on Linux servers
• Administrative access to Wazuh Dashboard
• OpenSearch Security administrator privileges
• Access to Wazuh configuration files
• Access to service restart commands

You’ll also need administrative permissions within your Identity Provider to:

• Create applications
• Configure redirect URLs
• Generate client secrets
• Download metadata
• Configure SAML assertions
• Configure OIDC claims
• Assign user groups

Without administrator access on both sides, the SSO configuration cannot be completed.

TLS Certificates Configured

SSO protocols rely heavily on encrypted communication.

Before configuring authentication, verify that:

• HTTPS is enabled
• Valid TLS certificates are installed
• Certificate chains are complete
• Hostnames match certificate Common Names (CN) or Subject Alternative Names (SAN)

Improper TLS configuration commonly results in:

• Redirect failures
• Invalid issuer errors
• Certificate validation failures
• Browser security warnings
• Metadata download failures

Self-signed certificates can work for testing, but production deployments should use certificates issued by a trusted Certificate Authority (CA).

If your deployment currently has certificate issues, resolve those first.

Related Guide: How to Fix Wazuh Certificate Errors

Identity Provider Account

You’ll need an existing Identity Provider (IdP) capable of supporting either SAML 2.0 or OpenID Connect.

For each provider, you’ll typically create a new enterprise application representing your Wazuh Dashboard.

During setup you’ll usually collect information such as:

• Client ID
• Client Secret
• Issuer URL
• Authorization Endpoint
• Token Endpoint
• Metadata URL
• Signing Certificate
• Entity ID
• Redirect URI
• Logout URL

These values are later referenced within the OpenSearch Security configuration.

Network Connectivity Between Wazuh and the IdP

Authentication requires reliable communication between your Wazuh Dashboard, OpenSearch, users’ browsers, and the Identity Provider.

Verify that:

• DNS resolution works
• HTTPS traffic is allowed
• Firewalls permit outbound connections
• Reverse proxies preserve authentication headers
• Load balancers correctly handle redirects
• Time synchronization (NTP) is functioning

Blocked HTTPS traffic or DNS failures frequently cause authentication redirects to fail before users even reach the login page.

You can validate connectivity using tools such as:

curl https://your-idp.example.com

or

openssl s_client -connect your-idp.example.com:443

If Wazuh is deployed behind NGINX or another reverse proxy, ensure authentication headers and redirect URLs are forwarded correctly.

Related Guide: How to Configure a Wazuh Proxy

Backup of Current Authentication Configuration

Before making any authentication changes, create backups of the existing security configuration.

Important files may include:

• OpenSearch Security configuration
• Authentication domain configuration
• Role mappings
• Internal users
• Certificates
• Dashboard configuration
• Wazuh configuration files

A simple backup can significantly reduce recovery time if authentication fails.

For example:

cp -r /etc/wazuh-indexer /root/wazuh-indexer-backup

or create a full VM snapshot before modifying production authentication.

If administrators become locked out after an incorrect SSO configuration, restoring these files is often the fastest recovery method.

Supported Identity Providers

Because Wazuh authentication is handled through the OpenSearch Security plugin, it supports a wide range of enterprise identity providers that implement either SAML 2.0 or OpenID Connect (OIDC).

Most modern enterprise identity platforms can integrate with Wazuh without requiring custom authentication code.

Microsoft Entra ID (Azure AD)

Microsoft Entra ID is one of the most common identity providers used with Wazuh.

It supports:

• OpenID Connect
• OAuth 2.0
• SAML 2.0
• Conditional Access
• Multi-Factor Authentication
• Group-based authorization
• Identity Protection

Organizations already using Microsoft 365 can typically integrate Wazuh using their existing Entra tenant.

Common use cases include:

• Enterprise SOCs
• Government organizations
• Healthcare
• Financial institutions

Okta

Okta provides cloud-native identity management and supports both SAML and OpenID Connect integrations.

Key capabilities include:

• Universal Directory
• Adaptive MFA
• Lifecycle management
• Device trust
• Group synchronization
• Risk-based authentication

Many organizations choose Okta when managing hybrid cloud applications alongside on-premises infrastructure.

Google Workspace

Organizations using Google Workspace can authenticate users with Wazuh through Google Identity.

Supported features include:

• OpenID Connect
• OAuth 2.0
• SAML
• Multi-factor authentication
• Centralized user management
• Group-based access control

Google Workspace is commonly used by startups, educational institutions, and cloud-native organizations.

Keycloak

Keycloak is a popular open-source Identity and Access Management (IAM) platform.

It is particularly attractive for organizations that prefer self-hosted identity infrastructure.

Keycloak supports:

• SAML
• OpenID Connect
• LDAP federation
• Active Directory integration
• Social login
• MFA
• User federation
• Fine-grained role mapping

Because it’s open source, Keycloak is frequently deployed alongside self-hosted Wazuh environments.

Ping Identity

Ping Identity is widely used in large enterprises requiring advanced identity governance.

It offers:

• SAML
• OpenID Connect
• Passwordless authentication
• Adaptive authentication
• Identity federation
• Single Logout (SLO)
• Enterprise directory integration

It is especially common within regulated industries that require sophisticated access control policies.

Auth0

Auth0 provides developer-friendly identity management with extensive customization options.

Features include:

• OpenID Connect
• OAuth 2.0
• SAML
• MFA
• Social authentication
• Enterprise federation
• Custom authentication flows

Its flexibility makes it popular for organizations integrating both internal and customer-facing applications.

OneLogin

OneLogin supports enterprise SSO with centralized identity management.

Capabilities include:

• SAML
• OIDC
• LDAP connectors
• Directory synchronization
• MFA
• User provisioning
• Application catalog

It offers straightforward integration for organizations managing large numbers of SaaS applications.

Generic SAML Providers

Any standards-compliant SAML 2.0 identity provider can typically integrate with Wazuh.

Examples include:

• Active Directory Federation Services (AD FS)
• Shibboleth
• ForgeRock
• Oracle Identity Cloud Service
• IBM Security Verify

Configuration usually involves exchanging:

• Metadata XML
• Signing certificates
• Assertion Consumer Service (ACS) URLs
• Entity IDs
• NameID formats
• Attribute mappings

Generic OpenID Connect Providers

Similarly, any OpenID Connect-compliant provider should work with Wazuh.

Typical configuration requires:

• Discovery URL
• Client ID
• Client Secret
• Redirect URI
• Authorization Endpoint
• Token Endpoint
• UserInfo Endpoint
• JSON Web Key Set (JWKS)

OpenID Connect has become the preferred protocol for many modern cloud deployments due to its simplicity and native JSON support.

Understanding SAML vs OpenID Connect

Before configuring Wazuh SSO, it’s important to understand the two authentication protocols you’ll most commonly encounter: SAML 2.0 and OpenID Connect (OIDC).

Both provide secure Single Sign-On, but they differ significantly in architecture, token formats, and deployment scenarios.

What Is SAML?

Security Assertion Markup Language (SAML) is an XML-based standard that enables identity providers to authenticate users for web applications.

Instead of sharing passwords, the identity provider sends a digitally signed SAML Assertion containing information about the authenticated user.

A typical SAML authentication includes:

• Identity Provider (IdP)
• Service Provider (SP)
• Browser redirects
• XML assertions
• Digital signatures
• Certificate validation

SAML has been widely adopted in enterprise environments for over a decade and remains the standard for many legacy and commercial identity platforms.

What Is OIDC?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0.

Rather than XML assertions, OIDC uses lightweight JSON Web Tokens (JWTs) to exchange identity information.

A successful login typically produces:

• ID Token
• Access Token
• Refresh Token (optional)

Because it is based on REST APIs and JSON, OIDC integrates naturally with modern cloud-native applications, APIs, and microservices.

Many newer enterprise deployments now default to OIDC instead of SAML due to its simplicity and developer-friendly design.

Key Differences

Although both protocols accomplish the same goal, their implementation differs considerably.

Security researchers generally recommend OpenID Connect for new cloud-native applications due to its simpler architecture, while SAML remains an excellent choice for organizations with existing enterprise federation infrastructure.

Authentication Flow Comparison

Although the user experience appears nearly identical, the underlying authentication sequence differs.

SAML flow

1. User requests the Wazuh Dashboard.
2. Browser redirects to the Identity Provider.
3. User authenticates.
4. The IdP creates a signed XML assertion.
5. Browser sends the assertion to Wazuh.
6. OpenSearch validates the signature.
7. User gains access.

OIDC flow

1. User requests the Wazuh Dashboard.
2. Browser redirects to the Identity Provider.
3. User authenticates.
4. The IdP issues a JWT ID Token.
5. OpenSearch validates the token.
6. User attributes are extracted.
7. Role mappings are applied.
8. Dashboard access is granted.

In both cases, Wazuh never receives or stores the user’s password, reducing credential exposure and centralizing authentication within the trusted Identity Provider.

Which Protocol Should You Choose?

The best choice depends on your existing identity infrastructure rather than on Wazuh itself.

Choose SAML if:

• Your organization already uses enterprise federation.
• You rely on legacy identity platforms.
• Existing applications already authenticate using SAML.
• Your IdP has mature SAML integrations.

Choose OpenID Connect if:

• You’re deploying a new environment.
• You primarily use cloud-native services.
• Your identity platform recommends OIDC.
• You want simpler configuration and troubleshooting.
• You expect to integrate APIs or mobile applications in the future.

For most new Wazuh deployments, OpenID Connect is generally the preferred option, while SAML remains an excellent choice for organizations with established enterprise SSO infrastructure.

Both protocols are fully capable of providing secure authentication when configured according to vendor best practices.

How to Configure Wazuh SSO Using OpenID Connect (OIDC)

OpenID Connect (OIDC) is the recommended authentication protocol for most new Wazuh deployments because it is built on OAuth 2.0, uses lightweight JSON Web Tokens (JWTs), and integrates seamlessly with modern identity providers.

While the exact configuration differs slightly between providers such as Microsoft Entra ID, Okta, and Keycloak, the overall process remains largely the same.

Configure the Identity Provider

Begin by creating a new application in your identity provider that represents your Wazuh Dashboard.

Typical configuration tasks include:

• Creating a new enterprise application
• Selecting OpenID Connect (OIDC)
• Assigning users or groups
• Configuring supported account types
• Enabling ID token issuance
• Configuring logout behavior
• Enabling Multi-Factor Authentication (optional but recommended)

Many identity providers also support Conditional Access policies, allowing administrators to require compliant devices, trusted locations, or phishing-resistant MFA before users can access Wazuh.

Register the Wazuh Application

Each identity provider requires an application registration that uniquely identifies Wazuh.

During registration you’ll typically define:

• Application name
• Redirect URI
• Application type (Web)
• Supported authentication protocol
• Login URL
• Logout URL (optional)

The application registration generates the identifiers that OpenSearch Security uses to authenticate users.

Configure Redirect URIs

Redirect URIs tell the identity provider where users should be returned after successful authentication.

A typical redirect URL resembles:

https://wazuh.example.com/auth/openid/login

The exact endpoint depends on your OpenSearch Security configuration and deployment.

When configuring redirect URIs:

• Always use HTTPS.
• Ensure the hostname matches the dashboard URL exactly.
• Avoid trailing slash mismatches.
• Register every production URL users may access.
• Add separate redirect URIs for test environments if necessary.

A mismatched redirect URI is one of the most common causes of OIDC login failures.

Obtain Client Credentials

After registering the application, your identity provider generates credentials used by Wazuh.

These typically include:

• Client ID
• Client Secret
• Issuer URL
• Discovery Endpoint
• Authorization Endpoint
• Token Endpoint
• JWKS Endpoint

Store these credentials securely, as the client secret authenticates your Wazuh instance to the identity provider.

Avoid embedding secrets directly into scripts or version-controlled repositories.

Update Wazuh Authentication Settings

Next, configure the OpenSearch Security plugin to use your OIDC provider.

This generally involves updating the authentication configuration to specify:

• OIDC authentication type
• Client ID
• Client Secret
• Issuer URL
• Discovery URL
• Requested scopes
• Username claim
• Backend role claim
• Session settings

Most deployments also configure:

• Token validation
• Signature verification
• Session timeout
• Logout behavior
• Token refresh policies

Refer to your identity provider’s documentation to ensure all endpoints and claims match the expected configuration.

Configure Scopes and Claims

Scopes determine which information Wazuh requests from the identity provider.

Common scopes include:

• openid
• profile
• email
• groups

The identity provider then returns claims such as:

• Username
• Email address
• Display name
• Group memberships
• Unique user identifier

These claims are later used for role mapping within Wazuh.

Ensure that group membership claims are included if you intend to assign permissions based on directory groups.

Restart Services

After saving the authentication configuration, restart the affected services so the changes take effect.

Depending on your deployment, restart:

systemctl restart wazuh-dashboard
systemctl restart wazuh-indexer

If you’re running a clustered deployment, restart nodes according to your maintenance procedures to minimize service disruption.

Related Guide: How to Build a Wazuh Indexer Cluster

Test Authentication

After the restart:

1. Open the Wazuh Dashboard.
2. Select the new SSO login option (if applicable).
3. Authenticate with your identity provider.
4. Complete MFA if required.
5. Confirm that the dashboard loads successfully.
6. Verify that the correct Wazuh role is assigned.
7. Check audit and authentication logs for any errors.

If authentication fails, review:

• Redirect URI configuration
• Client ID and secret
• Token claims
• Certificate validation
• Clock synchronization
• OpenSearch Security logs

Testing with a non-administrative account first is a good practice before migrating all users to SSO.

How to Configure Wazuh SSO Using SAML

SAML 2.0 remains a widely used authentication protocol in enterprise environments, particularly where organizations already maintain mature federation infrastructures.

The setup process focuses on establishing trust between the Identity Provider (IdP) and the Service Provider (SP), which in this case is the OpenSearch Security plugin protecting the Wazuh Dashboard.

Create the Service Provider

The first step is creating a Service Provider (SP) configuration for Wazuh.

The Service Provider identifies your Wazuh Dashboard to the Identity Provider and defines how authentication requests are handled.

Typical SP information includes:

• Entity ID
• Assertion Consumer Service (ACS) URL
• Single Logout URL (optional)
• Supported NameID formats
• Signing certificates

Many identity providers can automatically import this information using metadata files.

Configure Metadata

Metadata contains the information needed for both systems to trust each other.

The Service Provider metadata typically includes:

• Entity ID
• ACS endpoint
• Certificate information
• Supported bindings
• Signing requirements

Similarly, the Identity Provider provides metadata containing:

• Login endpoints
• Logout endpoints
• Public signing certificates
• Entity identifiers

Most enterprise identity providers allow metadata to be imported directly from a URL or XML file, simplifying configuration.

Exchange Certificates

SAML uses digital certificates to verify the authenticity of authentication messages.

During setup:

• Import the Identity Provider’s public certificate into OpenSearch Security.
• Configure the Service Provider certificate if message signing is enabled.
• Verify certificate validity periods.
• Confirm that trusted certificate chains are complete.

Expired or incorrect certificates are among the most common causes of SAML authentication failures.

Configure Assertion Consumer Service (ACS)

The Assertion Consumer Service (ACS) endpoint receives authentication assertions from the Identity Provider after a successful login.

When configuring the ACS:

• Use HTTPS.
• Ensure the URL matches exactly between the IdP and Wazuh.
• Verify that reverse proxies preserve request headers.
• Confirm that firewalls allow HTTPS traffic.

Even minor URL mismatches can prevent successful authentication.

Configure NameID

The NameID uniquely identifies the authenticated user.

Common NameID formats include:

• Email address
• User Principal Name (UPN)
• Persistent identifier
• Transient identifier
• Username

Choose a NameID format that remains stable over time and uniquely identifies each user within your organization.

Changing the NameID format after deployment may require updating existing role mappings.

Map SAML Attributes

In addition to the NameID, SAML assertions can include attributes such as:

• Username
• Email
• First name
• Last name
• Department
• Group membership
• Organizational unit

These attributes enable OpenSearch Security to map authenticated users to the appropriate Wazuh roles.

Verify that your Identity Provider includes all required attributes in the SAML assertion before testing authentication.

Restart Wazuh Services

After completing the configuration:

systemctl restart wazuh-dashboard
systemctl restart wazuh-indexer

If you’re deploying changes in a production cluster, consider restarting services during a maintenance window to minimize user impact.

Validate Authentication

Once services restart:

1. Browse to the Wazuh Dashboard.
2. Initiate SAML authentication.
3. Authenticate through the Identity Provider.
4. Complete MFA if configured.
5. Verify that authentication succeeds.
6. Confirm that the expected Wazuh role is assigned.
7. Review authentication logs for warnings or errors.

If users receive signature validation, audience restriction, or assertion expiration errors, review certificate configuration, metadata, and system time synchronization.

Configuring Role Mapping

Authentication confirms who a user is, while role mapping determines what that user is allowed to do within Wazuh.

After a user successfully authenticates through the Identity Provider, OpenSearch Security evaluates group memberships or claims and maps them to Wazuh Role-Based Access Control (RBAC) roles.

Well-designed role mappings simplify administration and improve security by automatically assigning permissions based on organizational groups.

Mapping IdP Groups to Wazuh Roles

Most organizations manage permissions using groups rather than assigning roles individually.

A common approach is:

Whenever users are added to or removed from these groups, their Wazuh permissions update automatically after the next authentication.

This significantly reduces ongoing administrative effort.

Administrator Roles

Administrator roles should be reserved for trusted personnel responsible for managing the Wazuh platform.

Typical privileges include:

• User management
• RBAC configuration
• Rule management
• Decoder creation
• Cluster administration
• Index management
• Dashboard configuration
• Integration management

Only a small number of users should receive these permissions.

Related Guide: Troubleshooting Wazuh RBAC

Analyst Roles

Security analysts typically require permissions to investigate alerts without modifying platform settings.

Analyst permissions commonly include:

• Viewing alerts
• Running searches
• Reviewing dashboards
• Investigating incidents
• Executing approved queries
• Viewing agent status
• Reviewing vulnerability data

Restricting administrative capabilities helps prevent accidental configuration changes while allowing analysts to perform their daily tasks effectively.

Read-Only Users

Read-only roles are ideal for:

• Auditors
• Executives
• Compliance teams
• Management
• External reviewers

These users can:

• View dashboards
• Generate reports
• Search alerts
• Monitor system health

They cannot:

• Modify rules
• Change configurations
• Delete data
• Manage users
• Alter role mappings

Read-only access supports governance requirements while protecting critical security configurations.

Custom Roles

Many organizations require permissions that do not fit standard administrator or analyst roles.

Examples include:

• Vulnerability management teams
• Threat intelligence analysts
• Incident response teams
• Compliance officers
• Infrastructure administrators
• MSSP customer administrators

Custom RBAC roles allow organizations to grant only the permissions necessary for each team’s responsibilities.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Group Synchronization

One of the primary advantages of SSO is automatic permission management through group synchronization.

Instead of manually updating Wazuh accounts:

• New employees inherit permissions from their assigned groups.
• Department transfers automatically update access after group membership changes.
• Disabled user accounts immediately lose access to Wazuh.
• Administrative workload is significantly reduced.

Many identity providers also support automated provisioning and deprovisioning through standards such as SCIM, further streamlining user lifecycle management.

Least-Privilege Access

Role mapping should follow the principle of least privilege, granting users only the permissions required to perform their job functions.

To implement least-privilege access effectively:

• Assign administrator roles sparingly.
• Use groups instead of individual user assignments.
• Separate operational and administrative responsibilities.
• Review role assignments regularly.
• Remove unnecessary permissions promptly.
• Audit privileged accounts periodically.
• Require MFA for all administrative users.

The National Institute of Standards and Technology recommends enforcing least privilege as a fundamental security control within its guidance on access control and digital identity management.

Configuring Multi-Tenant Access with SSO

Organizations such as Managed Security Service Providers (MSSPs), large enterprises, and government agencies often use Wazuh Multi-Tenancy to isolate data between customers, departments, or business units.

Combining multi-tenancy with Single Sign-On allows users to authenticate once through a centralized Identity Provider while automatically receiving access only to the tenants they are authorized to manage.

Instead of manually assigning tenant permissions within Wazuh for every user, administrators can leverage identity provider groups to automate tenant access and simplify ongoing administration.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Mapping Users to Tenants

After successful authentication, OpenSearch Security evaluates the user’s identity claims and group memberships before assigning access to one or more tenants.

A common mapping strategy might look like this:

This approach allows administrators to manage tenant access entirely through the Identity Provider without modifying Wazuh whenever personnel changes occur.

Tenant-Specific Permissions

Not every user within a tenant requires the same level of access.

Typical tenant permissions include:

Even within a single tenant, RBAC should restrict administrative capabilities to only those users responsible for managing the environment.

Group-Based Tenant Assignment

The most scalable deployment model uses identity provider groups to control tenant access.

For example:

• Customer-A-Admins → Customer A administrator
• Customer-A-Analysts → Customer A analyst
• Customer-B-Admins → Customer B administrator
• Customer-B-Analysts → Customer B analyst

When an employee changes departments or customer assignments, administrators simply update the user’s group membership within the Identity Provider. Their tenant access automatically changes during the next authentication.

This eliminates much of the manual effort associated with managing large Wazuh deployments.

Managing Multiple Organizations

Multi-tenant deployments are especially valuable for organizations responsible for monitoring multiple independent environments.

Examples include:

• Managed Security Service Providers (MSSPs)
• Consulting firms
• Universities
• Government agencies
• Healthcare systems
• Holding companies
• Global enterprises with regional security teams

Each organization can maintain:

• Separate dashboards
• Separate visualizations
• Separate saved searches
• Separate alert views
• Separate indexes (when configured)
• Independent access controls

Although authentication occurs through a single Identity Provider, data visibility remains isolated according to tenant assignments.

Multi-Tenant Best Practices

To maintain secure tenant isolation:

• Use Identity Provider groups rather than individual user assignments.
• Follow the principle of least privilege.
• Minimize the number of tenant administrators.
• Review tenant assignments regularly.
• Separate production and testing tenants.
• Audit privileged tenant access.
• Remove inactive users promptly.
• Require MFA for administrative accounts.
• Standardize group naming conventions across the organization.

Organizations with dozens or hundreds of tenants often automate group provisioning through identity governance tools, reducing administrative overhead while improving consistency.

Testing Your SSO Configuration

After completing your SSO setup, thoroughly validate the configuration before deploying it to production users.

Testing should confirm not only that authentication succeeds, but also that authorization, tenant isolation, session handling, and logout behavior work as expected.

Verify Login Flow

Start by testing the complete authentication process.

Verify that:

• The Wazuh Dashboard redirects users to the Identity Provider.
• HTTPS is used throughout the authentication process.
• Users authenticate successfully.
• MFA prompts appear when required.
• Users return to the dashboard without errors.
• Authentication completes within a reasonable amount of time.

Watch for common issues such as:

• Redirect loops
• Invalid redirect URIs
• Certificate errors
• Token validation failures
• Expired assertions
• Browser security warnings

Validate Role Assignments

After logging in, confirm that users receive the correct Wazuh role.

Test multiple account types, including:

• Administrator
• Security analyst
• Read-only user
• Auditor
• Custom role

Verify that each user can perform only the actions permitted by their assigned role.

For example:

• Administrators should manage rules and configuration.
• Analysts should investigate alerts.
• Read-only users should not modify any settings.

Related Guide: Troubleshooting Wazuh RBAC

Confirm Tenant Access

If you’re using multi-tenancy, verify that users can access only their assigned tenant.

Test scenarios such as:

• Customer A analyst attempting to access Customer B dashboards.
• Administrator assigned to multiple tenants.
• Newly assigned users.
• Users removed from a tenant group.
• Cross-tenant dashboard visibility.

No user should be able to view another tenant’s data unless explicitly authorized.

Related Guide: How to Set Up Wazuh Multi-Tenancy

Test Logout Behavior

Logging out should terminate the authenticated session completely.

Verify that:

• The Wazuh Dashboard logs out correctly.
• Sessions are removed from the browser.
• Single Logout (SLO) functions if configured.
• Returning to protected pages requires reauthentication.
• Browser back buttons cannot reopen authenticated sessions.

Incomplete logout behavior may leave active sessions accessible on shared workstations.

Verify Session Persistence

A properly configured session should remain active for an appropriate amount of time without unnecessarily interrupting users.

Confirm that:

• Sessions survive normal page navigation.
• Idle timeout works correctly.
• Session expiration forces reauthentication.
• Token refresh occurs as expected (OIDC).
• Session cookies use secure attributes.
• Multiple browser tabs behave consistently.

Excessively long session durations increase risk, while very short sessions may frustrate analysts during investigations.

Test Failover Scenarios

Production environments should also be tested for unexpected failures.

Examples include:

• Identity Provider outage
• DNS resolution failure
• Expired certificates
• Invalid client secrets
• OpenSearch node failure
• Network interruption
• Dashboard restart
• Reverse proxy restart

Document recovery procedures so administrators know how to restore access quickly if authentication services become unavailable.

Organizations with strict availability requirements often maintain documented “break glass” administrator accounts that can be used only during authentication emergencies.

Security Best Practices

Implementing SSO significantly improves security, but it should be accompanied by additional hardening measures to protect authentication infrastructure and privileged access.

The following best practices help reduce the risk of unauthorized access while improving operational resilience.

Always Use HTTPS

Every component involved in authentication should communicate over encrypted HTTPS connections.

This includes:

• Wazuh Dashboard
• OpenSearch
• Identity Provider
• Reverse proxies
• Load balancers

Never transmit authentication tokens over unencrypted HTTP.

Modern browsers may reject insecure authentication requests altogether, and attackers could intercept credentials or tokens if encryption is not enforced.

Validate Certificates

Certificate validation protects against impersonation and man-in-the-middle attacks.

Ensure that:

• Certificates are issued by a trusted Certificate Authority (CA).
• Certificate chains are complete.
• Hostnames match certificate names.
• Expired certificates are replaced promptly.
• Revoked certificates are removed.

Authentication failures caused by invalid certificates are often difficult to diagnose, making proactive certificate management essential.

Enable MFA at the Identity Provider

One of the greatest advantages of SSO is the ability to enforce Multi-Factor Authentication (MFA) centrally.

Require MFA for:

• Administrators
• Security analysts
• Remote users
• Privileged roles
• High-risk sign-ins

Whenever possible, prefer phishing-resistant authentication methods such as FIDO2 security keys or passkeys over SMS-based verification.

The Cybersecurity and Infrastructure Security Agency and National Institute of Standards and Technology both recommend phishing-resistant MFA as a key defense against credential theft.

Apply Least Privilege

Grant users only the permissions necessary to perform their responsibilities.

Best practices include:

• Limit administrative roles.
• Use read-only roles whenever possible.
• Separate administrative and analyst accounts.
• Review permissions regularly.
• Remove unnecessary access promptly.

Periodic access reviews help identify users who have accumulated excessive privileges over time.

Restrict Administrator Accounts

Administrative accounts should receive additional protection because they can modify authentication settings, RBAC policies, and platform configuration.

Consider implementing:

• Dedicated administrator accounts
• Mandatory MFA
• Conditional Access policies
• Device compliance requirements
• Login restrictions by geographic location
• Privileged Access Workstations (PAWs)

Avoid using administrator accounts for routine monitoring or investigations.

Protect Client Secrets

OIDC client secrets and signing keys should be treated as highly sensitive credentials.

Protect them by:

• Storing them securely.
• Restricting filesystem permissions.
• Avoiding source code repositories.
• Rotating secrets regularly.
• Limiting administrative access.
• Using secret management solutions when available.

If a client secret is compromised, an attacker may be able to impersonate your Wazuh application.

Configure Session Timeouts

Sessions should expire after a reasonable period of inactivity.

When defining timeout policies, balance usability with security.

Consider:

• Shorter idle timeouts for privileged users.
• Automatic reauthentication after extended sessions.
• Secure cookie attributes.
• Token expiration limits.
• Proper logout enforcement.

These controls reduce the risk of unauthorized access through abandoned or unattended browser sessions.

Rotate Certificates Regularly

Authentication certificates should not remain unchanged indefinitely.

Establish a documented rotation process that includes:

• Monitoring certificate expiration dates.
• Renewing certificates before expiration.
• Testing new certificates in a staging environment.
• Removing expired certificates.
• Updating metadata when required.

Automated certificate management can reduce operational overhead and help prevent unexpected authentication outages.

Monitor Authentication Logs

Authentication logs provide valuable insight into both operational issues and potential security incidents.

Monitor for:

• Failed login attempts
• MFA failures
• Unexpected administrator logins
• Role mapping errors
• Token validation failures
• Certificate validation errors
• Repeated redirects
• Unusual geographic login locations

Forwarding authentication logs into Wazuh enables centralized monitoring and alerting on suspicious authentication activity.

Related Guide: How to Configure Wazuh as a Centralized Syslog Server

Keep Wazuh Updated

Security updates frequently include fixes for authentication libraries, OpenSearch Security components, TLS handling, and RBAC improvements.

To maintain a secure environment:

• Apply supported Wazuh releases promptly.
• Keep OpenSearch components updated.
• Update the Wazuh Dashboard alongside the Indexer and Manager.
• Review release notes before upgrading.
• Test authentication changes in a staging environment before deploying them to production.

Regular updates reduce exposure to known vulnerabilities and help ensure continued compatibility with evolving identity providers and authentication standards.

Common Wazuh SSO Problems and Solutions

Although SSO simplifies authentication management, configuration mistakes between Wazuh, OpenSearch Security, and the Identity Provider can cause login failures.

Most Wazuh SSO issues fall into a few categories:

• Incorrect endpoint configuration
• Certificate problems
• Token or assertion validation failures
• Missing identity attributes
• Incorrect RBAC mappings
• Network connectivity problems

Understanding the most common failures makes troubleshooting significantly faster.

Login Redirect Loops

A login redirect loop occurs when users are continuously redirected between the Wazuh Dashboard and the Identity Provider without successfully completing authentication.

Common causes include:

• Incorrect redirect URI configuration
• Invalid session cookies
• Reverse proxy misconfiguration
• Incorrect authentication domain settings
• Failed token validation
• Browser cookie restrictions

To troubleshoot redirect loops:

1. Verify the redirect URI matches exactly between Wazuh and the IdP.
2. Clear browser cookies and test again.
3. Check Wazuh Dashboard logs.
4. Review OpenSearch Security authentication logs.
5. Confirm HTTPS is configured correctly.
6. Verify the IdP successfully issues tokens or assertions.

Browser developer tools can also help identify whether the failure occurs during:

• Authorization redirect
• Token exchange
• Session creation
• Dashboard loading

Invalid Redirect URI

An invalid redirect URI error occurs when the Identity Provider receives an authentication request containing a callback URL that does not match the registered application configuration.

Common causes include:

• HTTP instead of HTTPS
• Incorrect hostname
• Missing port number
• Extra trailing slash
• Incorrect reverse proxy URL
• Multiple dashboard URLs without registration

For example:

Configured:

https://wazuh.example.com/auth/openid/login

Requested:

https://security.example.com/auth/openid/login

The IdP will reject the request because the URLs do not match.

To fix this:

• Copy the exact redirect URI from the Wazuh configuration.
• Add all approved production URLs to the IdP.
• Avoid using wildcard redirects in production.
• Confirm proxy forwarding settings.

Certificate Validation Failures

Certificate problems are among the most common causes of SSO authentication failures.

Symptoms include:

• Unable to verify issuer
• Signature validation failed
• Metadata download errors
• Invalid certificate chain
• Expired certificate errors

Common causes include:

• Expired IdP signing certificates
• Missing intermediate certificates
• Incorrect CA trust store
• Self-signed certificates without proper configuration
• Clock-related certificate validation issues

Troubleshooting steps:

1. Verify certificate expiration dates.
2. Confirm the certificate matches the IdP metadata.
3. Import required CA certificates.
4. Restart Wazuh services after certificate changes.
5. Test certificate validation manually.

Example:

openssl s_client -connect idp.example.com:443

SAML Assertion Errors

SAML authentication failures often occur because the assertion generated by the Identity Provider does not match what OpenSearch expects.

Common SAML errors include:

• Invalid audience
• Invalid issuer
• Assertion expired
• Signature validation failure
• Missing NameID
• Missing required attributes

Check:

• Entity ID configuration
• ACS URL
• Signing certificate
• Assertion expiration time
• NameID format
• Attribute mappings

A SAML debugging tool or browser extension can help inspect the returned assertion and verify that required attributes are present.

OIDC Token Validation Failures

OIDC authentication depends on validating JSON Web Tokens (JWTs).

Common failures include:

• Invalid issuer
• Invalid audience
• Expired token
• Invalid signature
• Missing claims
• Incorrect discovery endpoint

Troubleshooting steps:

Verify:

• Issuer URL matches the Identity Provider.
• Client ID matches the registered application.
• JWKS endpoint is reachable.
• Required claims exist.
• System clocks are synchronized.

OIDC providers commonly expose a discovery endpoint:

https://identity-provider.example.com/.well-known/openid-configuration

This endpoint provides:

• Authorization URL
• Token URL
• JWKS URL
• Supported claims

Clock Synchronization Issues

Authentication protocols rely heavily on accurate timestamps.

Incorrect system time can cause:

• Expired SAML assertions
• Invalid JWT timestamps
• Certificate validation errors
• Session creation failures

Ensure all systems use synchronized time:

• Wazuh Manager
• Wazuh Dashboard
• Wazuh Indexer
• Identity Provider
• Domain controllers
• Authentication servers

Verify time synchronization:

timedatectl status

Enable NTP synchronization:

timedatectl set-ntp true

A few minutes of clock drift can be enough to break authentication.

Missing User Attributes

After authentication succeeds, Wazuh may fail to assign permissions if required user attributes are missing.

Common missing attributes include:

• Username
• Email address
• Groups
• Roles
• Department information

For example, if role mapping expects:

groups = SOC-Administrators

but the IdP only sends:

email = user@example.com

the user may authenticate but receive no permissions.

To fix this:

• Review IdP claims configuration.
• Add missing attributes.
• Verify attribute names match Wazuh configuration.
• Test with a sample user.

Incorrect Role Mappings

Users may successfully authenticate but receive incorrect permissions because their identity groups do not map correctly to Wazuh roles.

Common causes include:

• Incorrect group names
• Case-sensitive mismatches
• Missing backend role mappings
• Incorrect claim names
• Cached authentication information

Example:

Identity Provider sends:

Wazuh-SOC-Admins

Role mapping expects:

SOC-Admins

The user will not receive administrator permissions.

Troubleshooting steps:

• Review IdP group claims.
• Compare exact group names.
• Validate OpenSearch role mappings.
• Test with a known administrator account.

Group Synchronization Problems

Group synchronization issues occur when Wazuh does not receive updated directory group information.

Possible causes:

• Incorrect group claims
• Directory synchronization delays
• Nested group limitations
• Missing permissions in the IdP application
• Token caching

Solutions include:

• Enable group claims.
• Verify application permissions.
• Reduce unnecessary group assignments.
• Test with direct group membership.
• Refresh user sessions after group changes.

Users typically need to log out and authenticate again before updated group memberships appear.

Session Timeout Issues

Incorrect session settings can create either security risks or poor user experiences.

Common symptoms:

• Users are logged out too quickly.
• Sessions remain active too long.
• Tokens expire unexpectedly.
• Dashboard access fails after inactivity.

Review:

• Wazuh Dashboard session timeout.
• IdP token expiration.
• Refresh token lifetime.
• Browser cookie expiration.
• Reverse proxy timeout settings.

Session policies should balance security requirements with analyst workflow needs.

Monitoring SSO Authentication

Monitoring authentication activity provides visibility into user access, operational problems, and potential security threats.

Since SSO centralizes authentication through an Identity Provider, organizations should monitor both:

• Identity Provider authentication logs
• Wazuh/OpenSearch security events

Combining both sources provides a complete view of user activity.

Authentication Success Logs

Successful authentication events help verify normal user activity.

Track information such as:

• Username
• Authentication timestamp
• Source IP address
• Identity provider
• Authentication method
• MFA status
• Assigned roles
• Tenant access

Successful login monitoring helps identify:

• Unexpected administrator access
• Unusual login locations
• New user activity
• Authentication configuration issues

Failed Login Attempts

Failed authentication attempts are important security signals.

Monitor for:

• Repeated failed logins
• Password attacks
• MFA failures
• Disabled account attempts
• Invalid tokens
• Expired certificates
• Authentication misconfigurations

A sudden increase in failed SSO attempts may indicate:

• Credential compromise attempts
• Misconfigured applications
• Identity provider outages

Wazuh can create detection rules to alert security teams when authentication behavior becomes abnormal.

Related Guide: How to Create Custom Detection Rules in Wazuh (With Examples)

Group Mapping Events

Track changes to user groups and role assignments.

Important events include:

• User added to administrator groups
• User removed from security groups
• Tenant access changes
• Privilege escalation attempts

Monitoring group changes is especially important because identity provider groups often directly control Wazuh permissions.

Session Activity

Session monitoring helps identify abnormal usage patterns.

Review:

• Active sessions
• Session duration
• Login frequency
• Concurrent sessions
• Session termination events

Potential indicators include:

• Multiple simultaneous sessions from unusual locations.
• Long-running privileged sessions.
• Access outside normal working hours.

Administrative Actions

Privileged actions should receive additional monitoring.

Track:

• Role changes
• User permission changes
• Authentication configuration changes
• Tenant modifications
• Dashboard administration actions

Administrative activity should be reviewed regularly, especially in environments containing sensitive security data.

Audit Logging

Audit logging provides accountability by recording who performed actions and when.

Enable logging for:

• Authentication events
• Authorization decisions
• Configuration changes
• Role modifications
• Tenant access changes

Audit logs support:

• Compliance requirements
• Incident investigations
• Access reviews
• Security monitoring

Related Guide: How to Configure Wazuh Log Retention

Detecting Suspicious Login Behavior

SSO logs can reveal suspicious patterns that may indicate compromised accounts.

Examples include:

• Impossible travel scenarios
• Repeated authentication failures
• Login attempts from unusual countries
• Privileged account usage anomalies
• Access outside expected schedules
• Unexpected MFA failures

Security teams can combine Identity Provider logs with Wazuh detection rules to create automated alerts.

Performance Considerations

Although SSO generally improves administration, authentication introduces additional dependencies on identity providers and network services.

Proper planning ensures reliable authentication performance, especially in large Wazuh deployments.

Token Caching

Token caching reduces unnecessary authentication requests.

Benefits include:

• Faster dashboard access
• Reduced IdP load
• Better user experience
• Lower authentication latency

However, token lifetimes must be balanced carefully.

Long-lived tokens:

• Improve convenience
• Increase security risk if compromised

Short-lived tokens:

• Improve security
• Increase authentication frequency

Session Management

Efficient session management helps maintain performance and security.

Consider:

• Appropriate session expiration times
• Secure cookie configuration
• Token refresh settings
• Maximum concurrent sessions
• Idle timeout policies

Large SOC environments with many analysts should test session behavior under realistic workloads.

Identity Provider Latency

Every SSO login depends on communication with the Identity Provider.

Authentication delays may occur due to:

• Network latency
• Geographic distance
• IdP performance issues
• DNS delays
• Certificate validation delays

Reduce latency by:

• Using regional IdP infrastructure.
• Ensuring reliable DNS.
• Monitoring IdP availability.
• Optimizing network routes.

High Availability IdPs

Production Wazuh environments should consider Identity Provider availability.

A failed IdP can prevent users from accessing the dashboard.

High availability strategies include:

• Multiple IdP instances
• Geographic redundancy
• Disaster recovery procedures
• Backup administrator accounts
• Documented recovery processes

Authentication availability should be included in overall Wazuh disaster recovery planning.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Large Directory Environments

Organizations with thousands of users and groups should carefully design identity synchronization.

Potential challenges include:

• Large group claims
• Excessive token size
• Slow directory searches
• Complex nested groups
• Increased authentication processing

Best practices:

• Send only required groups.
• Avoid unnecessary directory attributes.
• Use dedicated security groups.
• Keep role mappings simple.
• Periodically remove unused groups.

Authentication Scalability

Large Wazuh deployments should test authentication capacity before production rollout.

Consider:

• Number of concurrent users
• Login spikes after outages
• SOC shift changes
• IdP rate limits
• Token validation workload
• Network capacity

For large environments, combine:

• High availability Wazuh components
• Reliable Identity Provider infrastructure
• Proper session management
• Monitoring of authentication performance

A well-designed SSO architecture ensures that centralized authentication improves security without becoming a bottleneck for security operations.

Wazuh-Admins → Administrator Role

Wazuh-Analysts → Analyst Role

Wazuh-Auditors → Read-Only Role