How to Configure Wazuh SAML Authentication

Example SAML Authentication Flow

Understanding the complete authentication sequence makes it much easier to troubleshoot login problems and verify that each component is functioning correctly.

While individual Identity Providers may implement minor variations, the overall SAML authentication workflow remains largely the same.

User Requests Wazuh Dashboard

The authentication process begins when a user navigates to the Wazuh Dashboard.

At this point, Wazuh checks whether the user already has a valid authenticated session.

• If an active session exists, the dashboard loads immediately.
• If no session exists, Wazuh initiates the SAML authentication process by redirecting the user’s browser to the configured Identity Provider.

No credentials are entered into Wazuh itself.

Redirect to Identity Provider

Instead of displaying a local login page, the Wazuh Dashboard sends an authentication request (AuthnRequest) to the Identity Provider.

This request typically contains:

• Service Provider Entity ID
• Assertion Consumer Service (ACS) URL
• Requested authentication context
• Request ID
• RelayState (optional)

The browser is then redirected to the Identity Provider’s login page.

User Authentication

The Identity Provider authenticates the user according to the organization’s security policies.

Depending on the environment, authentication may include:

• Username and password
• Passwordless authentication
• Multi-factor authentication (MFA)
• Smart cards
• FIDO2 security keys
• Biometric authentication
• Conditional Access policies
• Risk-based authentication

Since authentication occurs entirely at the Identity Provider, organizations can enforce consistent security controls across all enterprise applications.

SAML Assertion Returned

Once authentication succeeds, the Identity Provider generates a signed SAML assertion containing the authenticated user’s identity.

A typical assertion includes:

• User identifier (NameID)
• Email address
• Display name
• Group memberships
• Assigned roles
• Authentication timestamp
• Session expiration
• Issuer information
• Audience restrictions

The browser automatically submits this assertion to Wazuh’s Assertion Consumer Service (ACS) endpoint.

Signature Validation

Before trusting the assertion, Wazuh performs several security checks.

These include validating:

• XML digital signature
• Signing certificate
• Assertion issuer
• Audience restriction
• Assertion expiration
• Replay protection
• Request correlation
• Certificate trust chain

If any validation fails, authentication is rejected.

Session Creation

After successful validation, Wazuh creates an authenticated session for the user.

The session generally includes:

• Secure authentication cookie
• Session identifier
• User attributes
• Assigned roles
• Session timeout
• Idle timeout

Users can now access the dashboard without authenticating again until the session expires or they log out.

Authorization Based on Mapped Roles

Authentication only confirms the user’s identity. Authorization determines what the user is allowed to do.

Wazuh evaluates the mapped groups or role attributes received from the Identity Provider and assigns the appropriate RBAC permissions.

For example:

This separation of authentication and authorization allows organizations to manage permissions centrally without creating local Wazuh accounts.

Configuring Popular Identity Providers

Although every Identity Provider has its own administration interface, the configuration process follows the same general pattern:

1. Create a SAML application.
2. Configure the Wazuh Service Provider settings.
3. Exchange metadata.
4. Configure user attributes.
5. Configure group mappings.
6. Test authentication.

Below are examples for several widely used Identity Providers.

Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory) is one of the most common enterprise Identity Providers used with Wazuh.

Enterprise Application Setup

To begin:

1. Open the Microsoft Entra admin center.
2. Navigate to Enterprise Applications.
3. Create a new enterprise application.
4. Choose Create your own application.
5. Select Integrate any other application you don’t find in the gallery (Non-gallery).
6. Configure the application for SAML-based Single Sign-On.

After the application is created, configure the basic SAML settings using your Wazuh Dashboard’s Entity ID and ACS URL.

Claims Configuration

Configure the claims that Wazuh will receive within the SAML assertion.

Typical claims include:

• NameID
• Username
• Email
• Display name
• Given name
• Surname
• Group membership

Ensure that the NameID format aligns with your Wazuh user mapping configuration.

Group Assignments

Assign users or security groups to the enterprise application.

Most organizations create dedicated groups such as:

• Wazuh Administrators
• SOC Analysts
• Incident Responders
• Compliance Auditors
• Read-Only Users

These groups can later be mapped directly to Wazuh RBAC roles.

Testing Login

Before production deployment:

• Test administrator authentication.
• Test analyst authentication.
• Verify group membership.
• Confirm role assignments.
• Validate logout functionality.
• Review Entra sign-in logs for any authentication errors.

Keycloak

Keycloak is a popular open-source Identity Provider for organizations hosting their own authentication infrastructure.

Realm Creation

Create or select an existing realm that will contain the Wazuh application.

Within the realm:

• Configure users.
• Configure groups.
• Configure roles.
• Enable MFA if required.

Using a dedicated realm for security applications simplifies administration in larger environments.

Client Configuration

Create a new client using the SAML protocol.

Configure:

• Client ID (Entity ID)
• Assertion Consumer Service URL
• Signature requirements
• Redirect URLs
• Logout URL
• NameID format

Enable signed assertions for improved security.

Protocol Mappers

Protocol mappers define which user attributes are included in the SAML assertion.

Common mappings include:

• Username
• Email
• Display name
• Groups
• Realm roles
• Client roles

Only expose the attributes required by Wazuh to minimize unnecessary data sharing.

Role Synchronization

Map Keycloak groups or realm roles to Wazuh RBAC roles.

For example:

Automated role synchronization significantly reduces ongoing administrative effort.

Okta

Okta provides one of the most mature SAML implementations available for enterprise environments.

SAML Application Configuration

Create a custom SAML application within the Okta administration console.

Configure:

• Single Sign-On URL
• Audience URI (Entity ID)
• NameID format
• RelayState (optional)
• Signature settings

Import the Wazuh metadata where supported to simplify configuration.

Attribute Statements

Configure attribute statements that Wazuh will consume.

Typical examples include:

• Email
• Username
• Display name
• First name
• Last name
• Groups

Ensure the attribute names match those expected by your Wazuh configuration.

Group Assignments

Assign users using Okta groups rather than individual accounts.

This simplifies:

• User onboarding
• Offboarding
• Permission updates
• RBAC management

Group-based authorization is considerably easier to maintain than manually assigning permissions to individual users.

Testing Authentication

Validate:

• Successful authentication
• Correct group mappings
• Proper RBAC permissions
• Session creation
• Single Logout (if configured)

Review Okta system logs if authentication does not complete successfully.

Google Workspace

Google Workspace can also function as a SAML Identity Provider for Wazuh.

Custom SAML Application

Within the Google Admin Console:

1. Create a custom SAML application.
2. Upload the Service Provider metadata.
3. Configure ACS URL.
4. Configure Entity ID.
5. Download Google’s IdP metadata.

Assign the application to the appropriate organizational units or user groups.

User Attribute Mapping

Map user attributes such as:

• Primary email
• First name
• Last name
• Display name
• Organizational unit
• Groups (where supported)

Verify that the selected attributes match your Wazuh configuration.

Certificate Configuration

Import Google’s signing certificate into the Wazuh Dashboard.

Verify:

• Certificate fingerprint
• Validity dates
• Trusted issuer
• Signature verification

Monitor certificate expiration to prevent unexpected authentication failures.

Login Verification

After completing the configuration:

• Authenticate with a Google Workspace account.
• Verify the dashboard loads successfully.
• Confirm RBAC permissions.
• Test session expiration.
• Test logout behavior.

If users are unable to authenticate, review the Google Workspace SAML application configuration alongside the Wazuh authentication logs.

Managing Users and Permissions

One of the primary advantages of SAML authentication is centralized identity and permission management.

Instead of creating and maintaining local user accounts, organizations can control access entirely through their Identity Provider.

Combined with Wazuh’s Role-Based Access Control (RBAC), this approach provides a scalable and secure authorization model for enterprise environments.

Group-Based Authorization

Most organizations assign permissions using identity groups rather than individual user accounts.

Examples include:

When a user’s group membership changes, their Wazuh permissions are automatically updated during the next authentication.

This greatly simplifies onboarding, transfers between teams, and employee offboarding.

Role-Based Access Control (RBAC)

After successful authentication, Wazuh assigns permissions based on mapped RBAC roles.

RBAC controls access to resources such as:

• Dashboards
• Alerts
• Indexes
• Agents
• Rules
• API endpoints
• Cluster management
• Administrative settings

Carefully designed RBAC policies help enforce the principle of least privilege while minimizing the risk of accidental or unauthorized changes.

For a detailed explanation of permission troubleshooting, see Troubleshooting Wazuh RBAC.

Automatic User Provisioning

SAML enables Just-In-Time (JIT) user provisioning in many environments, allowing users to be recognized and assigned permissions automatically upon their first successful login, depending on the capabilities of the Identity Provider and Wazuh configuration.

Benefits include:

• No manual account creation
• Faster onboarding
• Centralized lifecycle management
• Automatic access removal when accounts are disabled
• Reduced administrative overhead

Organizations should verify how their chosen Identity Provider and Wazuh version handle user provisioning before deployment.

Least Privilege Access

Security best practices recommend granting users only the permissions required to perform their responsibilities.

For example:

• SOC analysts should investigate alerts but not modify cluster settings.
• Compliance personnel should review reports without changing detection rules.
• Security engineers may require administrative access to configure integrations and policies.
• Executives often need read-only dashboards for operational visibility.

Following the principle of least privilege limits the impact of compromised accounts and helps satisfy regulatory requirements such as NIST SP 800-53 and the CIS Critical Security Controls, both of which emphasize minimizing unnecessary privileges.

Managing Administrative Accounts

Administrative accounts should receive additional protections because they have broad access to the Wazuh platform.

Recommended practices include:

• Assign administrator privileges only through dedicated identity groups.
• Require phishing-resistant MFA for all privileged accounts.
• Avoid using shared administrator accounts.
• Regularly review group memberships and role assignments.
• Audit administrative login activity and permission changes.
• Maintain separate administrative and standard user accounts for day-to-day operations.

You should also periodically verify that privileged users retain only the access necessary for their current responsibilities, removing outdated assignments as personnel or job functions change.

Security Best Practices

Implementing SAML authentication is only the first step toward securing access to your Wazuh environment.

Following security best practices helps protect user identities, prevent unauthorized access, and maintain compliance with industry standards.

Enforce HTTPS Everywhere

All communication between users, the Wazuh Dashboard, and the Identity Provider should occur over HTTPS.

Using TLS protects:

• Authentication requests
• SAML assertions
• Session cookies
• User credentials
• Administrative sessions

Avoid allowing HTTP access, even on internal networks, as unencrypted traffic is vulnerable to interception and session hijacking.

If you’re deploying Wazuh behind a reverse proxy, ensure HTTPS is enforced end-to-end.

Require Multi-Factor Authentication (MFA)

One of the biggest advantages of SAML is that authentication policies are managed centrally by the Identity Provider.

Require MFA for all users, particularly those with privileged access.

Recommended authentication methods include:

• Authenticator applications
• FIDO2 security keys
• Smart cards
• Passkeys
• Hardware tokens

The Cybersecurity and Infrastructure Security Agency (CISA) strongly recommends phishing-resistant MFA as a key defense against credential theft and account compromise.

Protect Signing Certificates

SAML assertions rely on digital signatures to verify authenticity.

Protect signing certificates by:

• Storing private keys securely
• Restricting certificate access
• Using hardware security modules (HSMs) when appropriate
• Monitoring certificate validity
• Preventing unauthorized certificate replacement

Compromised signing certificates can undermine the trust relationship between Wazuh and the Identity Provider.

Rotate Certificates Before Expiration

Expired certificates are one of the most common causes of unexpected SAML authentication failures.

Establish a certificate management process that includes:

• Monitoring expiration dates
• Renewing certificates well before expiration
• Updating metadata after certificate changes
• Testing authentication before deploying new certificates
• Maintaining rollback procedures

Automated certificate monitoring can help prevent production outages.

Limit Administrator Access

Administrator accounts should be assigned only to personnel who require full administrative privileges.

Best practices include:

• Using dedicated administrator groups
• Avoiding shared administrator accounts
• Reviewing administrator memberships regularly
• Requiring stronger authentication policies
• Logging privileged activities

Reducing the number of privileged accounts lowers the potential impact of compromised credentials.

Use Least Privilege Roles

Not every authenticated user requires administrative access.

Instead, create separate RBAC roles for different responsibilities, such as:

• Tier 1 SOC analysts
• Tier 2 investigators
• Threat hunters
• Compliance auditors
• Security engineers
• Executive viewers

Grant only the permissions necessary for each role.

Enable Audit Logging

Comprehensive audit logging provides visibility into authentication activity and administrative changes.

Capture events including:

• Successful logins
• Failed logins
• Role assignments
• Group changes
• Configuration modifications
• Certificate updates
• Administrative actions

These logs are valuable for compliance, forensic investigations, and troubleshooting.

Monitor Authentication Events

Authentication monitoring helps identify suspicious activity before it becomes a security incident.

Watch for:

• Repeated login failures
• Unexpected login locations
• Authentication outside business hours
• Multiple failed MFA attempts
• Disabled accounts attempting access
• Unexpected administrator logins

Integrating authentication logs into your security monitoring process enables faster detection of potential attacks.

Keep Clocks Synchronized

SAML assertions include timestamps that define when they become valid and when they expire.

Synchronize:

• Wazuh servers
• Dashboard hosts
• Identity Providers
• Domain controllers
• Virtual machines

Using Network Time Protocol (NTP) across your infrastructure minimizes authentication failures caused by clock drift.

Regularly Review Group Memberships

Because access is controlled through Identity Provider groups, periodically verify that group memberships remain accurate.

Review:

• Administrative groups
• SOC teams
• Contractor accounts
• Disabled users
• Temporary access assignments

Routine access reviews help enforce the principle of least privilege and reduce the risk of excessive permissions.

Monitoring SAML Authentication

After deploying SAML authentication, ongoing monitoring is essential for detecting configuration issues, investigating login failures, and identifying suspicious authentication activity.

Monitoring should include both the Wazuh platform and the external Identity Provider.

Dashboard Authentication Logs

The Wazuh Dashboard records authentication events that help diagnose login issues.

Useful events include:

• Successful logins
• Failed logins
• Redirect failures
• Session creation
• Session termination
• Assertion validation errors

These logs are often the first place to investigate when users report authentication problems.

Wazuh Logs

In addition to dashboard logs, review Wazuh server logs for authentication-related events.

Look for:

• Authentication provider initialization
• Metadata loading
• Certificate validation
• SAML parsing errors
• Authorization failures
• RBAC assignment issues

Centralized logging makes it easier to correlate authentication events with other security activity.

Failed Authentication Attempts

Repeated authentication failures may indicate:

• Incorrect credentials
• Expired certificates
• Identity Provider outages
• Replay attacks
• Automated password guessing
• Configuration errors

Monitor trends rather than isolated events to identify potential security concerns.

Session Monitoring

Monitor active sessions to understand how users interact with the Wazuh Dashboard.

Track information such as:

• Active sessions
• Session duration
• Idle timeouts
• Concurrent sessions
• Unexpected session persistence

Reviewing session activity can help identify abandoned sessions or unauthorized access.

Certificate Expiration Monitoring

Because SAML depends on trusted certificates, monitor certificate validity proactively.

Track:

• Expiration dates
• Certificate rotations
• Trust chain changes
• Newly imported certificates
• Metadata updates

Setting alerts well before expiration reduces the likelihood of authentication outages.

Identity Provider Logs

Most Identity Providers provide detailed authentication logs that complement Wazuh’s logging.

Typical events include:

• Login successes
• Login failures
• MFA challenges
• Conditional Access decisions
• Group membership evaluation
• Assertion generation
• Application assignments

Correlating Identity Provider logs with Wazuh logs helps isolate whether a failure occurred before or after the SAML assertion was issued.

Audit Events

Regularly audit authentication-related activity to support security investigations and compliance requirements.

Important events include:

• Role assignment changes
• Group membership modifications
• Administrative logins
• Certificate replacements
• Configuration changes
• Failed authorization attempts
• Single Logout events

If your deployment includes multiple business units or customers, auditing authentication alongside access controls becomes even more important.

Common Wazuh SAML Authentication Problems and Solutions

Although SAML is a mature authentication standard, configuration errors are common during initial deployment.

Most issues stem from incorrect metadata, certificate problems, or mismatched configuration values between Wazuh and the Identity Provider.

The following troubleshooting tips cover some of the most frequent problems encountered when configuring Wazuh SAML authentication.

Login Redirect Loop

If users are repeatedly redirected between the Wazuh Dashboard and the Identity Provider without successfully logging in, the SAML authentication process is not completing correctly.

Common causes include:

• Incorrect Assertion Consumer Service (ACS) URL
• Invalid Entity ID
• Cookie or browser session issues
• Misconfigured redirect URLs
• Reverse proxy configuration errors

Incorrect ACS URL

Verify that the Assertion Consumer Service URL configured in the Identity Provider exactly matches the URL configured in Wazuh.

Check for:

• Incorrect protocol (HTTP vs. HTTPS)
• Typographical errors
• Missing path components
• Trailing slash differences

Even minor mismatches can prevent the Identity Provider from delivering the SAML assertion correctly.

Invalid Entity ID

The Service Provider Entity ID must match on both sides of the configuration.

Confirm that:

• The Entity ID is identical in Wazuh and the IdP.
• No extra whitespace or trailing slashes are present.
• The correct application is referenced.

Cookie Issues

Authentication loops can also occur when session cookies are not stored correctly.

Potential causes include:

• Browser privacy settings
• SameSite cookie restrictions
• Third-party cookie blocking
• Reverse proxy cookie handling
• Expired session cookies

If you encounter cookie-related issues, review Fixing Wazuh API SameSite Cookie Errors.

Invalid SAML Assertion

If Wazuh rejects the SAML assertion, authentication will fail before a user session is created.

Possible causes include:

• Certificate mismatch
• Expired assertion
• Incorrect audience value
• Invalid signature
• Corrupted metadata

Certificate Mismatch

Verify that Wazuh is using the current signing certificate published by the Identity Provider.

If the IdP recently rotated certificates, update the imported metadata or certificate in Wazuh before testing again.

Expired Assertion

SAML assertions are valid only for a limited period.

Authentication may fail if:

• The assertion expires before validation.
• Network delays are excessive.
• System clocks are not synchronized.

Incorrect Audience

The audience restriction in the SAML assertion must match the configured Service Provider Entity ID.

Review both the IdP and Wazuh configuration to ensure they reference the same Entity ID.

User Authenticates but Has No Permissions

In some cases, authentication succeeds but the user cannot access dashboards or resources because authorization has failed.

This typically indicates a problem with role mapping rather than authentication.

Missing Group Mapping

Confirm that:

• The user belongs to the expected Identity Provider group.
• The group is included in the SAML assertion.
• The group is mapped to a Wazuh RBAC role.

If no matching group is found, Wazuh cannot assign permissions.

Incorrect Role Mapping

Review the configured RBAC mappings and verify that each Identity Provider group is associated with the intended Wazuh role.

Attribute Name Mismatch

Different Identity Providers use different attribute names for groups and user information.

For example:

• groups
• memberOf
• roles
• securityGroups

Ensure the attribute names configured in Wazuh match those included in the SAML assertion.

Certificate Validation Errors

Certificate validation problems typically prevent Wazuh from trusting the Identity Provider.

Expired Certificates

Verify that all signing certificates remain valid.

If a certificate has expired:

• Renew the certificate.
• Export updated metadata.
• Import the new certificate into Wazuh.
• Test authentication.

Incorrect Metadata

Outdated or manually edited metadata can contain invalid endpoints or certificates.

Whenever possible, download fresh metadata directly from the Identity Provider instead of editing XML files manually.

Missing Signing Certificate

If the Identity Provider’s signing certificate is missing from the Wazuh configuration, signature validation will fail.

Ensure the correct public certificate is installed and trusted before enabling SAML authentication.

Clock Synchronization Errors

Time synchronization problems frequently cause SAML authentication failures because assertions include strict validity windows.

Time Drift

Even a clock difference of a few minutes between the Identity Provider and Wazuh can result in rejected assertions.

Verify that all participating systems maintain accurate time.

NTP Configuration

Configure reliable Network Time Protocol (NTP) servers on:

• Wazuh Manager
• Wazuh Dashboard
• Identity Provider
• Domain controllers
• Supporting infrastructure

Regular synchronization minimizes authentication issues caused by timestamp validation.

Assertion Expiration

If authentication consistently fails with expired assertions:

• Verify system clocks.
• Check time zones.
• Confirm assertion lifetime settings.
• Review network latency if users authenticate across geographically distributed environments.

Single Logout Not Working

Single Logout (SLO) can be more complex to implement than standard SSO because it requires coordination between the Identity Provider and the Service Provider.

Missing SLO Endpoint

Verify that both the Identity Provider and Wazuh are configured with matching Single Logout URLs.

If one side does not advertise an SLO endpoint, logout requests may not propagate correctly.

Session Configuration

Review session timeout settings and logout behavior to ensure sessions are terminated consistently across all integrated applications.

Confirm that:

• Session cookies are cleared.
• Active sessions are invalidated.
• Browser caches are not preserving stale authentication state.

Identity Provider Limitations

Not every SAML Identity Provider implements Single Logout in the same way, and some offer only partial support.

Consult your Identity Provider’s documentation to confirm:

• Whether SLO is supported.
• Which bindings are available (HTTP-Redirect, HTTP-POST, etc.).
• Any provider-specific configuration requirements or limitations.

If reliable SLO is not available, configure appropriate session timeout policies as a fallback to reduce the risk of long-lived authenticated sessions.

Performance and High Availability Considerations

While SAML authentication does not typically create significant performance overhead, enterprise deployments should carefully plan identity infrastructure, session management, and certificate lifecycle processes to ensure reliable authentication at scale.

A well-designed SAML architecture prevents authentication outages from impacting SOC operations and ensures that users can continue accessing Wazuh during Identity Provider maintenance or infrastructure failures.

Identity Provider Redundancy

The Identity Provider becomes a critical dependency once SAML authentication is enabled.

If the IdP becomes unavailable, users may be unable to authenticate into Wazuh, even if the Wazuh platform itself is fully operational.

Enterprise environments should consider:

• Highly available Identity Provider deployments
• Multiple authentication servers
• Geographic redundancy
• Backup authentication methods
• Disaster recovery procedures

Examples include:

• Microsoft Entra ID global availability
• Highly available Keycloak clusters
• Multi-node identity platforms
• Secondary authentication providers

Organizations should document recovery procedures for Identity Provider outages, including emergency administrator access methods.

Session Timeout Configuration

Proper session management balances security and usability.

Short sessions improve security but may interrupt SOC workflows, while long sessions increase exposure if an account or workstation is compromised.

Consider configuring:

• Idle session timeout
• Maximum session duration
• Automatic logout
• Reauthentication requirements
• Privileged user session limits

Recommended policies often include:

• Shorter sessions for administrators
• Longer sessions for analysts performing continuous monitoring
• Mandatory reauthentication for sensitive actions

Session policies should align with organizational security requirements and compliance frameworks.

Authentication Latency

SAML authentication requires communication between multiple components:

1. User browser
2. Wazuh Dashboard
3. Identity Provider
4. Authentication services
5. Directory services

Authentication delays may occur due to:

• Slow Identity Provider response times
• Network latency
• Large directory searches
• Excessive group memberships
• Complex conditional access policies
• MFA delays

To improve authentication performance:

• Optimize Identity Provider queries.
• Avoid sending unnecessary user attributes.
• Limit excessive group claims.
• Use efficient directory searches.
• Deploy Identity Provider infrastructure close to users when possible.

Metadata Refresh Strategy

SAML metadata contains important trust information, including:

• Identity Provider endpoints
• Entity identifiers
• Signing certificates
• Supported bindings

Organizations should establish a metadata update process.

Recommended practices include:

• Regularly checking for metadata changes
• Updating metadata before certificate expiration
• Testing changes in staging environments
• Documenting metadata ownership
• Monitoring certificate rollover events

Automatic metadata refresh, when supported, reduces the risk of authentication failures caused by outdated configuration.

Certificate Lifecycle Management

Certificates are one of the most important components of a SAML deployment.

Poor certificate management can result in unexpected authentication outages.

Establish a lifecycle process covering:

• Certificate creation
• Secure storage
• Distribution
• Monitoring
• Renewal
• Rotation
• Revocation

Recommended practices include:

• Track certificate expiration dates.
• Rotate certificates before expiration.
• Maintain certificate inventories.
• Test new certificates before production rollout.
• Update Wazuh metadata after certificate changes.

Scaling Large Enterprise Deployments

Large organizations may have thousands of users accessing Wazuh through SAML authentication.

To support enterprise-scale deployments:

• Use centralized group management.
• Avoid manually assigning permissions.
• Limit unnecessary group claims.
• Use automated identity lifecycle processes.
• Implement structured RBAC models.
• Separate administrator and analyst roles.
• Monitor authentication performance.

For organizations operating multiple security teams or customer environments, combine SAML with Wazuh multi-tenancy and RBAC controls.

See:

• How to Set Up Wazuh Multi-Tenancy
• Troubleshooting Wazuh RBAC

Real-World Example: Enterprise Wazuh SAML Authentication Deployment

A large enterprise security team operates a centralized Wazuh deployment used by multiple security groups, including SOC analysts, incident responders, threat hunters, and security administrators.

Previously, the organization managed local Wazuh accounts manually.

As the security team expanded, this created several challenges:

• Delayed onboarding for new analysts
• Manual permission changes
• Difficulty removing departed employees
• Inconsistent MFA enforcement
• Increased administrative workload

To solve these issues, the organization implemented SAML authentication using Microsoft Entra ID as the Identity Provider.

Integrating Microsoft Entra ID as the Identity Provider

The security team creates a dedicated SAML enterprise application in Microsoft Entra ID representing the Wazuh Dashboard.

The configuration includes:

• Wazuh Service Provider Entity ID
• Assertion Consumer Service URL
• SAML signing certificate
• User attribute mappings
• Group claims

The organization assigns security groups to the application, including:

• Wazuh Administrators
• SOC Analysts
• Incident Responders
• Compliance Auditors
• Security Managers

Each group represents a different level of access.

Synchronizing Security Groups With Wazuh RBAC Roles

The organization maps Entra ID security groups to Wazuh RBAC permissions.

Example:

When an employee changes departments, administrators only update the user’s group membership in Entra ID.

Wazuh permissions automatically update during the next authentication.

Enforcing Multi-Factor Authentication

The organization enables Microsoft Entra Conditional Access policies requiring MFA for all Wazuh users.

Additional controls include:

• Strong authentication requirements for administrators
• Device compliance checks
• Risk-based authentication
• Location-based restrictions
• Privileged account monitoring

This ensures that compromised passwords alone cannot provide access to the security platform.

Configuring Department-Based Access

Different departments receive different levels of access.

For example:

SOC Analysts

Access:

• Security alerts
• Dashboards
• Endpoint investigations

Restrictions:

• No cluster configuration
• No user management

Incident Responders

Access:

• Advanced investigations
• Threat analysis
• Response workflows

Administrators

Access:

• Configuration changes
• Agent management
• Integration management

This structure enforces least privilege while allowing teams to perform their responsibilities efficiently.

Validating Authentication Before Production Rollout

Before enabling SAML for all users, the security team performs staged testing.

Validation includes:

• Administrator login testing
• Analyst login testing
• MFA verification
• Group membership testing
• RBAC permission validation
• Logout testing
• Certificate validation

The team also maintains a rollback plan to restore local authentication if unexpected issues occur.

Benefits Achieved

After implementing SAML authentication, the organization achieves:

Simplified User Management

User creation and removal are handled centrally through the Identity Provider.

Stronger Security

MFA, conditional access, and centralized policies protect Wazuh access.

Reduced Administrative Overhead

Security administrators no longer manually manage individual Wazuh accounts.

Improved Compliance

Centralized authentication logs and access reviews support security audits and regulatory requirements.

Better Scalability

The organization can add new teams and users without increasing Wazuh administration workload.

Frequently Asked Questions

Question: What is Wazuh SAML authentication?

Wazuh SAML authentication allows users to authenticate to the Wazuh Dashboard through an external Identity Provider using the Security Assertion Markup Language standard.

Instead of managing local Wazuh accounts, organizations authenticate users through platforms such as Microsoft Entra ID, Okta, or Keycloak.

Question: Does Wazuh support SAML 2.0?

Yes. Wazuh supports SAML-based authentication through the Wazuh Dashboard and OpenSearch Security authentication mechanisms.

SAML 2.0 enables integration with enterprise Identity Providers that support the standard.

Question: Which identity providers work with Wazuh?

Wazuh can integrate with most SAML 2.0-compatible Identity Providers, including:

• Microsoft Entra ID
• Okta
• Keycloak
• Google Workspace
• Ping Identity
• OneLogin
• ADFS
• Other SAML-compliant platforms

Question: Can I use Microsoft Entra ID with Wazuh?

Yes. Microsoft Entra ID is one of the most common Identity Providers used for Wazuh SAML authentication.

Organizations can synchronize Entra security groups with Wazuh RBAC roles and enforce Microsoft MFA policies.

Question: Can I use Keycloak for Wazuh SAML authentication?

Yes. Keycloak is a popular open-source Identity Provider that supports SAML 2.0.

It is commonly used by organizations that want self-hosted identity management.

Question: How is SAML different from OIDC in Wazuh?

SAML and OpenID Connect (OIDC) both provide Single Sign-On capabilities but use different protocols.

SAML remains widely used in enterprise environments, while OIDC is increasingly common in cloud-native applications.

Question: Does Wazuh support Single Sign-On (SSO) with SAML?

Yes. SAML authentication provides Single Sign-On capabilities by allowing users to authenticate through an existing Identity Provider.

Users can access Wazuh without maintaining separate credentials.

Question: Can I map Active Directory groups to Wazuh roles?

Yes. Active Directory groups can be synchronized through supported Identity Providers such as Microsoft Entra ID or ADFS.

Groups can then be mapped to Wazuh RBAC roles.

Question: Why am I getting an invalid SAML assertion error?

Common causes include:

• Incorrect Entity ID
• Invalid ACS URL
• Expired assertion
• Certificate mismatch
• Incorrect audience value
• Clock synchronization problems

Review both Wazuh logs and Identity Provider logs to identify the cause.

Question: How do I troubleshoot Wazuh SAML login failures?

Start by checking:

1. Identity Provider authentication logs.
2. Wazuh Dashboard logs.
3. SAML metadata configuration.
4. Certificate validity.
5. Attribute mappings.
6. RBAC role mappings.

Common issues are caused by mismatched URLs, certificates, or user attributes.

Question: Does SAML authentication support multi-factor authentication?

Yes. MFA is typically enforced by the Identity Provider.

For example:

• Microsoft Entra MFA
• Okta Adaptive MFA
• Keycloak OTP
• Google Workspace MFA

Question: Can I configure high availability for SAML authentication?

Yes. High availability is achieved primarily through redundant Identity Provider infrastructure.

Organizations should also:

• Maintain certificate backups.
• Monitor metadata changes.
• Configure reliable DNS.
• Test disaster recovery procedures.
• Maintain emergency administrative access.

Conclusion

Wazuh SAML authentication provides organizations with a secure and scalable way to integrate the Wazuh Dashboard with enterprise identity platforms.

By delegating authentication to a centralized Identity Provider, organizations can:

• Enable Single Sign-On
• Enforce MFA policies
• Centralize user management
• Automate access provisioning
• Reduce administrative overhead
• Improve security visibility
• Support compliance requirements

A properly configured SAML deployment also simplifies permission management by connecting Identity Provider groups with Wazuh RBAC roles.

Security teams can ensure that analysts, incident responders, administrators, and auditors receive only the access required for their responsibilities.

Before deploying SAML authentication in production, test the configuration in a staging environment.

Validate authentication flows, certificate trust, group mappings, RBAC permissions, and logout behavior before migrating all users.

For additional Wazuh authentication and access management resources, continue with these related guides:

• How to Configure Wazuh SSO
• Troubleshooting Wazuh RBAC
• How to Set Up Wazuh Multi-Tenancy
• Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

By combining SAML authentication, strong identity controls, and carefully designed RBAC policies, organizations can build a secure Wazuh environment that scales with their security operations.