Keycloak and Wazuh SSO integration for your security team
Your security team runs the Wazuh dashboard, and you want analysts to sign in through the same central identity provider as your other internal tools instead of maintaining local dashboard accounts. The supported method for this integration is SAML 2.0, with Keycloak as the identity provider and the Wazuh indexer and Wazuh dashboard acting as the service providers. Before you plan the work, confirm that this combination matches the Wazuh single sign-on documentation for the Wazuh version you run, because the configuration keys and file locations are specific to each release line.
The integration covers four areas. The first is a SAML client in Keycloak for the Wazuh service provider, including the entity and assertion consumer settings the dashboard expects. The second is a Roles mapper that places the user's Keycloak roles or groups into a SAML attribute the Wazuh side can read. The third is the saml_auth_domain configuration in the Wazuh indexer security settings, which defines how the indexer trusts assertions from Keycloak. The fourth is backend role mapping, which connects the roles arriving from Keycloak to Wazuh permissions, so that one group receives administrator access and another receives read-only access. Each of these must agree with the others, and a mismatch in any one usually appears as a failed sign-in or as a user who signs in with no useful permissions.
The integration does not manage the user lifecycle beyond sign-in. Creating, disabling and removing analysts, and deciding who belongs to the administrator group, remain Keycloak tasks that your identity team should own and review. Wazuh agent enrollment is also outside this work. Agents on endpoints authenticate to the Wazuh server through their own enrollment process, and enabling dashboard sign-in does not change how those agents connect. Plan these areas separately so that nobody assumes the SSO project has solved access reviews or endpoint onboarding.
Decide early which Keycloak groups map to administrator and read-only access, and who approves changes to that mapping. Keep local break-glass accounts on the Wazuh indexer and dashboard under documented control, so that a Keycloak outage or a misconfigured assertion does not lock every operator out of the platform. Test the sign-in path with a non-administrator account first, then confirm that the administrator path grants only the permissions you intended. Record the exact Wazuh and Keycloak versions used in the test, since both products change their SAML handling over time.
Ask any implementation partner to show the written configuration for each component, the role mapping table, and the test cases used to prove both access levels. Confirm with your Wazuh and Keycloak administrators which versions are in production, whether the indexer and dashboard certificates are managed by your existing PKI, and how the team will handle SAML certificate rotation after go-live. These answers determine how much of the work is one-time setup and how much becomes recurring maintenance.
What you need before configuring Keycloak and Wazuh SSO
Single sign-on for the Wazuh dashboard depends on several systems agreeing before any SAML setting is changed. The cards below cover the versions to confirm, the working deployments and access paths, the certificate and DNS choices, and the Keycloak and Wazuh configuration access you need. Check each item in your own environment first, because a gap in one of them usually appears later as a login failure.
Software versions to confirm
Confirm the Wazuh release you run before you read any SAML settings. Wazuh 4.14 is the current release line, and 4.14.9 was released on 14 October 2026, so check whether your deployment is on that patch level or an earlier 4.14 release. Keycloak 26.8.1 is the current Keycloak release, published on October 13, 2026. Record both versions and follow the configuration steps in the documentation for those exact releases.
Working Wazuh deployment and access path
Wazuh must already run end to end before SSO is added. The indexer stores alerts, the server analyzes agent data, and the dashboard serves the web interface. Confirm that an administrator can sign in with the existing local account and reach the dashboard from the network where your users work. Note any load balancer or proxy in front of the dashboard, because the SAML redirect must return through that same path.
Keycloak over HTTPS with a trusted certificate
Keycloak must be reachable over HTTPS with a valid certificate that both Keycloak and the Wazuh indexer trust. Keycloak's production guidance calls for TLS on all communication and a reverse proxy in front of the server. Confirm that the certificate chain is issued by an authority the indexer already trusts, or that you can add it to the indexer's trust store, and that the indexer can reach Keycloak over that connection.
Separate DNS names for dashboard and Keycloak
Give the Wazuh dashboard and Keycloak their own DNS names. Keycloak's production guidance says the admin console and Administration REST API should sit on a different hostname or context path from public frontend URLs, so the login address users see should not be the address used for administration. Confirm that both names resolve from the user network and from the Wazuh indexer, and that the certificate covers each name.
Keycloak realm with test users and groups
Create a dedicated realm for Wazuh, separate from the master realm used for Keycloak administration. Add test users to at least two groups that match the access levels you plan to grant, such as administrators and read-only analysts. Group names become the values your role mapping matches, so agree on them before you configure the client. Test with accounts that you can disable without affecting production staff.
Wazuh indexer and security configuration access
Have administrative access to the Wazuh indexer and its security configuration files before you start. The SAML authentication domain and the role mapping are set in those files, so confirm that you can read and edit them and that you know how your installed version applies and reloads security changes. Keep a copy of the current configuration so you can restore it if a test login locks out every administrator.
How the SAML login flow works between Keycloak and the Wazuh dashboard
The SAML login flow is where most Keycloak and Wazuh integrations succeed or fail, so the first thing to understand is who does what at each step. When an analyst opens the Wazuh dashboard, the dashboard does not check a password itself. It redirects the browser to Keycloak, which acts as the SAML identity provider and authenticates the user against whatever directory or local account store the realm uses. After a successful sign-in, Keycloak returns a signed SAML assertion to the dashboard through the browser. The dashboard passes that assertion to the Wazuh indexer security layer, which validates it and uses the attributes it contains to decide what the analyst can see and do. The Wazuh side of this exchange is the part teams most often misread, so treat the assertion as the only thing that crosses the trust boundary between the two systems.
Several Keycloak client settings must line up with what Wazuh expects, and a mismatch in any one of them usually produces a redirect loop or a rejected assertion rather than a clear error. The entity ID on the Keycloak client has to match the identifier configured for the Wazuh service provider. The assertion consumer URL has to point at the dashboard endpoint that Wazuh listens on, using the scheme and hostname that users actually type into their browsers. The signing settings decide whether Keycloak signs the assertion, which signature algorithm it uses and which certificate the Wazuh indexer trusts to verify it. Before go-live, confirm each of these values against the Wazuh single sign-on documentation for your release line, and record the exact certificate fingerprint and entity ID in your change record so the next person can reproduce the setup.
The Roles mapper is the component that decides which roles reach Wazuh. In Keycloak, a mapper copies user or group role membership into an attribute of the outgoing assertion. Wazuh then matches the values in that attribute against the backend roles defined in its security configuration, and those backend roles are what map to administrator or read-only access. If the mapper emits the wrong attribute name, emits group paths where Wazuh expects role names, or omits roles for users who belong only to a parent group, the user will authenticate successfully and still land with no useful access. This is why role mapping should be tested with at least one account per intended access level, not only with an administrator account, which can mask gaps.
Attribute names are the detail to verify rather than assume. The exact attribute name that carries roles, and the naming convention that the indexer security configuration expects, should be taken from the Wazuh single sign-on documentation for the version you deploy, then compared against a live assertion captured from a test login. Keycloak can show the assertion contents in its event or debugging tools, and a SAML tracer in the browser can confirm what the dashboard received. Document the attribute names, the mapper settings and the backend role names together, because a Keycloak upgrade or a change to group structure can silently change the assertion even when the Wazuh configuration has not changed.
Plan for two operational risks before users depend on this login. The first is certificate rotation: when Keycloak's signing key changes, the Wazuh indexer must trust the new certificate, or every login fails at once, so decide who owns that change and how it is tested. The second is lockout: keep a local administrator path to the indexer that does not depend on SAML, and confirm how it is protected, so that a misconfigured mapper cannot shut every administrator out of the platform. Ask the team that will run the system to walk through a failed login on purpose and confirm that the error points them to the right layer.
Configuration sequence for Keycloak SAML with Wazuh
This sequence takes a Keycloak realm from an empty SAML client to a working Wazuh dashboard sign-in, in which assertion roles decide whether a user gets administrator or read-only access. Each step closes with a check, so a fault is caught where it was introduced. The order matters because the indexer cannot map roles that the assertion does not carry.
Create the SAML client in the realm
A Keycloak administrator creates a SAML client in the realm that holds the Wazuh dashboard's users, using a client ID that matches the entity ID the dashboard sends. Keep this client in the same realm as the people who need access so role assignments stay in one place. Confirm the exact entity ID value against the Wazuh single sign-on documentation for your 4.14 release before saving, because a mismatch stops every later step. The step is complete when the client appears in the realm's client list with the SAML protocol set and no other protocol attached.
Set client URLs and signing options
The administrator sets the valid redirect and assertion consumer URLs to the Wazuh dashboard's SAML endpoint, served over HTTPS under the hostname users type in their browsers. Choose whether Keycloak signs the assertion, the response or both, and select the signature algorithm the dashboard documentation expects. Keep the dashboard hostname identical in the client settings and the browser address so the redirect is accepted. Check: reopen the client settings, confirm the endpoints and signing options match the dashboard configuration, and record the values in your change log.
Add the Roles mapper to the client
The administrator adds a role list protocol mapper to the client so the user's roles are written into the SAML attribute statement under one attribute name. That name must be the one the Wazuh indexer reads, so agree it with the team that maintains the indexer before setting it. Create a test user with one administrator role and another test user with one read-only role. Check: use the client's evaluation function to generate a sample assertion for each test user, decode it, and confirm the roles appear under the expected attribute name with the expected values.
Export and verify the metadata and certificate
The administrator exports the realm's SAML identity provider descriptor and confirms it lists the single sign-on service location, the signing certificate and the entity ID that the dashboard expects. The team records the certificate fingerprint so it can compare the value after any future key rotation. The engineer then checks that the signing certificate is valid and has not expired, and that the single sign-on location resolves to the public hostname users reach. The step is complete when the descriptor parses cleanly and each value matches the client configuration from the earlier steps.
Configure saml_auth_domain in the indexer
The platform engineer adds a saml_auth_domain block to the Wazuh indexer security configuration on each node. The block carries the Keycloak identity provider details (the entity ID, the metadata or signing certificate from the previous step), the roles key that matches the Roles mapper attribute, and the dashboard callback address. Apply the change with the security administration tooling described in the Wazuh documentation for your release so the configuration is consistent across the cluster. Check: query the security configuration after applying it and confirm the saml_auth_domain entry is present and identical on every indexer node.
Map assertion roles to backend roles
In the indexer role mapping, the engineer maps each role value from the assertion to the Wazuh backend role for administrator access or for read-only access, following the built-in role definitions for your release. Apply least privilege: grant administrator only to a named Keycloak group, and let all other authenticated users land in read-only access. Remove any broad or unused mapping left from earlier testing. Check: list the role mapping and confirm that each assertion value maps to exactly one intended backend role, and that no account can reach administrator access by default.
Reload components and test sign-in
The engineer reloads the security configuration and restarts the dashboard and indexer components as the Wazuh single sign-on documentation requires for this change. If the cluster serves production users, the team restarts one node at a time to keep the service available. Then each test account signs in from a fresh browser session. Check: the administrator account lands on the expected dashboard view with management functions, the read-only account is refused those functions, and the indexer logs record both logins without errors. Keep the test results in your evidence record.
Mapping Keycloak roles to Wazuh administrator and read-only access
This table lists each Keycloak source role or group, the SAML attribute that carries it, the Wazuh backend role it maps to, the resulting access level and the owner who approves membership. Use it as a working record to agree the mapping with your security and identity owners before testing sign-in. Confirm the exact backend role names and mapping file format in the Wazuh single sign-on documentation, and review the table whenever Keycloak roles or groups change.
| Keycloak source | SAML attribute | Wazuh backend role | Access level and approver |
|---|---|---|---|
| Realm role wazuh-admin (illustrative) | Roles attribute carrying the realm role name, configured through the Keycloak Roles mapper | Administrator backend role named in the Wazuh SSO documentation (confirm exact name) | Full dashboard and API administration; approved by the SOC lead or security manager |
| Realm role wazuh-readonly (illustrative) | Roles attribute carrying the realm role name, configured through the Keycloak Roles mapper | Read-only backend role named in the Wazuh SSO documentation (confirm exact name) | View alerts and dashboards without configuration changes; approved by the SOC lead |
| Group /security/soc-analysts (illustrative) | Group membership attribute, only if the SAML client mapper exposes groups | Read-only or analyst backend role per the Wazuh mapping file format (confirm) | Investigation access without administration; approved by the SOC manager |
| Group /security/platform-admins (illustrative) | Group membership attribute, only if the SAML client mapper exposes groups | Administrator backend role per the Wazuh mapping file format (confirm) | Administration of the Wazuh stack; approved by the head of platform engineering |
| Users with no mapped role or group | Attribute absent or empty in the assertion | No backend role assigned, so sign-in should not grant dashboard access | Access denied by default; no approver needed, but confirm the Wazuh behavior in testing |
| Service or break-glass local account | Not carried in SAML assertions | Local Wazuh account kept outside SSO for recovery | Named owner records each use; approved by the CISO or delegate |
| Any role or group change in Keycloak | Mapper output changes when role or group names change | Mapping file and backend role assignments must match the new names | Review on every change, with sign-off from the identity owner and the Wazuh administrator |
Hardening the Keycloak and Wazuh SSO setup
The Keycloak and Wazuh sign-in path has several points where a weak setting lets an unauthorized user reach the dashboard or an administrator role. The cards below cover the controls to set and verify on the Keycloak client and the Wazuh side, along with the sign-in records Keycloak can provide once they are in place.
Require signed SAML assertions
Configure the Keycloak client to sign SAML assertions, and configure the Wazuh indexer to verify each assertion against the realm's signing certificate that you have pinned in its configuration. Confirm the certificate in Wazuh matches the active Keycloak realm key before go-live. Plan a dated process for rotating the key, because a stale or mismatched certificate either breaks sign-in or hides an unexpected key change. Repeat the signature check after each Keycloak upgrade.
Use HTTPS on both ends
Serve the Wazuh dashboard and Keycloak only over TLS, including the redirect and assertion consumer endpoints, so session cookies and SAML responses never travel in clear text. Check the certificate chain that the dashboard host presents, and confirm the Keycloak frontend URL uses https. Keycloak's production guidance calls for TLS on all communication, so treat any HTTP listener left open during testing as a finding to close before go-live.
Restrict valid redirect URIs
Set the Keycloak client's valid redirect URIs to the exact dashboard callback address, without wildcards or broad path patterns. Loose patterns can let a crafted login send a user's session to another host. Remove leftover entries from testing, such as local addresses or placeholder hosts, and confirm the web origins setting lists only the dashboard origin. Review both lists whenever the dashboard hostname or the client changes.
Keep administration off public hostnames
Keycloak's production guidance recommends exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Apply that split at the reverse proxy, restrict the admin path to management networks or VPN addresses, and test that an external request to the admin path is refused. Dashboard sign-in only needs the public frontend, so the administrative surface can stay internal.
Limit administrator and break-glass access
Wazuh maps SAML roles to backend roles that decide who gets administrator or read-only access. Keep the Keycloak group that carries administrator backend roles small and named, and record who approved each membership. Keep one local break-glass administrator under documented control, with its credential stored offline, its use logged and its access tested on a schedule, so that a Keycloak outage does not lock out every administrator.
Monitor sign-in activity
Start Keycloak with metrics enabled so Prometheus-format data is exposed on the management interface, then send that data to the monitoring stack your team already runs. Keycloak 26.8 persists login failures to the database by default, which gives reviewers a record of failed attempts to compare with Wazuh alerts. Confirm which metrics your release exposes, who reads them, and that the management endpoint stays off public hostnames.
How to test the Wazuh SSO login before users depend on it
Test the Wazuh SSO login with a fixed set of accounts before any operator is told to use it, and prove the local account fallback works before you cut over. The verification plan for this integration covers three things: that each Keycloak role lands in the correct Wazuh access level, that denied users are actually denied, and that sign-out, session expiry and audit logging behave as the operations team expects. Write the expected result for every test case before you run it, so a pass means something to the people who sign off on the cutover.
Create one test account per role in the Keycloak realm used for the Wazuh client. Include an administrator account mapped to the backend role that your saml_auth_domain configuration grants full access, a read-only account mapped to the read-only backend role, and a user with no mapped role. Sign in with each account through the Wazuh dashboard and confirm the access granted or denied matches your role mapping document. For the no-role account, the expected result is a successful Keycloak authentication followed by no usable Wazuh privileges. If that user can see indices or management screens, the mapping is too permissive and the cutover should stop.
Test the session lifecycle with the same accounts. Sign out from the dashboard and confirm that the Wazuh session ends and that reopening the dashboard requires a fresh Keycloak sign-in. Then review the session and token lifetimes configured in Keycloak and in the Wazuh dashboard, wait for expiry, and confirm the user is prompted to authenticate again. Also test the removal path: disable one test user in Keycloak, and separately remove a second one, then attempt sign-in with each. Record whether existing dashboard sessions survive the change, because that behavior determines how quickly an offboarded operator loses access in practice. Confirm the answer with your own environment rather than assuming it.
Check the audit trail in both systems after these tests. In Keycloak, confirm the sign-in events, failed attempts and account changes appear in the event store you have configured, and that the entries identify the test accounts. On the Wazuh side, confirm the authentication activity is visible in the indexer logs your security team reviews. Compare the two records for the same test sign-in so you know each failed or successful attempt can be traced end to end. Missing entries in either system are a finding to resolve before users depend on the login.
Plan the verification as a repeatable run, not a one-time event. Repeat the full set after every Keycloak upgrade and after every Wazuh patch release, because the 4.14 line has shipped patch releases roughly every one to two months. Before cutover, prove the rollback path: confirm that the local Wazuh account still signs in, that its permissions are correct, and that you can switch the SAML configuration off and restore local-only access within the window your operations team has agreed. Keep the local account credentials in your secrets store, restrict who can use them, and test that the rollback works on the same version you will run in production.
Common Keycloak and Wazuh SSO failures and their fixes
This table lists the most common failures when Keycloak signs users in to the Wazuh dashboard over SAML. Each row gives the likely cause, the fix and the check that confirms the fix worked. When a login fails, work through the rows in order, because clock, certificate and hostname problems often produce the same generic error.
| Failure | Likely cause | Fix and confirming check |
|---|---|---|
| Assertion signature validation error | Wrong or expired signing certificate in the Keycloak client or in the indexer trust configuration. | Re-import the current realm signing certificate into the SAML configuration. Confirm by signing in again and reviewing indexer logs for signature errors. |
| Redirect loop or invalid redirect URI | Dashboard hostname, Keycloak client redirect URI or proxy forwarding headers do not match. | Match the dashboard URL exactly in the client settings and forward host and protocol headers. Confirm with one traced login in the browser. |
| User signs in with no role | Roles mapper missing from the client scope, or the attribute name in the SAML response differs from the one Wazuh expects. | Add or correct the Roles mapper, then align attribute names with the backend role mapping. Confirm by inspecting the SAML response for a test user. |
| Assertion validity errors from time skew | Clock drift between Keycloak, the Wazuh indexer and the dashboard makes assertions appear not yet valid or expired. | Sync all servers to the same reliable time source. Confirm by comparing system clocks on each host and checking assertion timestamps. |
| Certificate trust failure between indexer and Keycloak | Keycloak's certificate is not trusted by the indexer truststore, often after a renewal or an internal CA change. | Add the issuing certificate authority to the indexer truststore and apply it to every node. Confirm with a metadata fetch from each indexer node. |
| Access denied after a role change | Backend role mapping was changed in Keycloak or Wazuh, but the indexer security configuration was not reloaded. | Reload the security configuration using the indexer's documented procedure, then sign out and back in. Confirm by checking the user's effective backend roles. |
Keeping Keycloak and Wazuh SSO working after go-live
Treat Keycloak releases as a recurring operational input. The project plans four minor releases a year, and since Keycloak 26.0 breaking changes in a minor release are opt-in, so an upgrade can still change behavior your Wazuh SAML client depends on. Read the upgrade notes for each target version before scheduling work. The 26.8 notes, for example, enforce SMTP StartTLS without plaintext fallback and make signature validation of backchannel logout tokens from external providers mandatory. Check each item against your own mail relay and logout settings in the realm. Then test the target version in a staging realm that mirrors the production client, mappers, certificates and Wazuh settings, and record the result before production is touched.
Plan Wazuh patching as a standing task. The 4.14 line has shipped patch releases roughly one every one to two months, with 4.14.8 on 23 September 2026 and 4.14.9 on 14 October 2026. Any patch to the Wazuh indexer, server or dashboard can change the code that handles SAML login, so treat each of those upgrades as a change to SSO. After every change, run the same short test: sign in with an administrator account, sign in with a read-only account, confirm each account sees only the expected views, sign out, and confirm the session ends. Record the Wazuh and Keycloak versions with each result so that a failed login can be traced to one change.
Track certificate expiry dates in the same register as the software versions. Include the TLS certificates on the Keycloak and Wazuh dashboard hostnames, the certificate or signing key that Wazuh uses to trust the Keycloak SAML metadata, and any certificate in the indexer trust chain. Read each expiry date from the live certificate and set reminders with enough lead time for the renewal, staging test and cutover. Ask your Keycloak and Wazuh implementation partner to document how a signing key rotation affects the Wazuh side, including whether the metadata must be re-imported. Pair this with a quarterly role review. Compare current Keycloak group membership with the Wazuh backend roles mapped to administrator and read-only access, remove leavers, and confirm that no account keeps administrator access through a stale group.
Assign named owners before go-live. The Keycloak client for Wazuh, including its redirect URIs, signing settings and attribute mappers, should have one owner in the identity team who approves every change. The Wazuh role mapping, which links backend roles to administrator or read-only access, should have an owner in the security operations team, because that team defines who needs which access. Name a deputy for each owner. Route changes on either side through the same ticket and staging test, so both owners know when the other side moved. Record the ownership, the test script and the version register in the runbook, and review the owners whenever staff change roles.
Questions buyers ask about Keycloak and Wazuh SSO
What drives the cost of Keycloak and Wazuh SSO work?
The cost follows the written scope. Five factors move it most: the number of Wazuh roles you need to map, how mature your Keycloak realm already is, the certificate and network work involved, the depth of testing, and whether your team already runs Wazuh.
Each role mapping adds configuration and verification. A realm with clean clients, groups and token mappers takes less discovery than one built ad hoc. Certificate work covers the SAML signing material and any internal certificate authority steps. Network work covers making sure the Wazuh components can reach the Keycloak metadata endpoint. Testing scope ranges from a single administrator sign-in to role-by-role verification. A team that already operates Wazuh shortens the discovery phase.
DeployOpen does not publish a price list. A quote follows from the written scope, which lists these items so you can see which ones apply to your environment.
How long does Keycloak and Wazuh SSO integration take?
The timeline depends on the scope in the written proposal and on how long approvals take in your organization, so no fixed duration applies to every engagement. Work that covers one Keycloak client, a short list of roles and a test in a non-production environment usually moves faster than work that spans several Wazuh deployments, multiple realms or a formal change window.
The steps that most often set the pace are approvals. These include change approval for the Keycloak client and for restarting Wazuh components, certificate issuance from your certificate authority, and booking a test window that does not collide with production monitoring. Ask for the milestone plan in the quote and list the approval gates it depends on. Submitting those requests early often shortens the project more than any configuration step.
What does DeployOpen need from our team to start?
Four inputs set the schedule: administrator access to Keycloak and to Wazuh, a named owner for role decisions, a test window, and contacts at your certificate authority.
Keycloak admin access lets the work create or update the SAML client, the Roles mapper and the test users. Wazuh admin access covers the dashboard and indexer configuration that points the platform at Keycloak. The role owner decides which Keycloak roles map to administrator access and which map to read-only access, since that choice defines who can change security settings. The test window should allow sign-in tests and a controlled restart of the Wazuh components. Certificate authority contacts supply or sign the certificates the SAML trust depends on.
Confirm these owners and access levels in the scope document before work starts.
Can our internal team set up Wazuh SSO alone?
Yes. A team with Keycloak and Wazuh experience can complete the integration using Wazuh's single sign-on documentation, and many teams do. That documentation covers the Wazuh side of the configuration, including the indexer SAML authentication domain and the role mapping that follows from it.
The documentation cannot decide how your Keycloak realm, client and role model should be designed, or how your certificates and network paths are arranged. Those design choices are where internal projects most often slow down.
Check three things before you start: whether someone on the team has done SAML work in Keycloak, whether you can test on a non-production Wazuh deployment, and who will own the role mapping after go-live. If any answer is no, a scoped engagement can cover the gap while your team keeps ownership of the running system.
What must the Keycloak client and mappers include for Wazuh?
The Keycloak side needs a SAML client that matches the Wazuh dashboard's entity and assertion consumer settings, plus a mapper that places the user's roles into the SAML assertion in a form Wazuh can read.
Get the entity identifier, the redirect address and the signing settings from the Wazuh configuration before you create the client. A mismatch there stops sign-in before any role is evaluated. Decide whether assertions are signed, and confirm that the signing certificate is one the Wazuh side trusts.
Test with one account in each role. The mapper must produce exactly the role names that the Wazuh configuration maps to administrator and read-only access, so write the role list down and check it on both sides. Keep a record of the client settings, because a Keycloak upgrade or a realm export can change them.
Does DeployOpen publish prices for Keycloak SSO work?
No. DeployOpen does not publish a price list, and a quote follows from the written scope. The scope names the Keycloak and Wazuh environments in play, the number of roles to map, the certificate and network steps, the testing you expect and the deliverables. Each of these adds cost, so a quote that lists them is easier to compare with an internal estimate or another proposal.
Ask the quote to separate one-time work, such as the initial configuration and testing, from recurring work, such as an ongoing support retainer if you want one. Ask who pays for each cost line, including any certificate authority fees your organization covers internally.
Any change to scope should be written down before work continues, so the final figure always matches what was agreed.
Does the integration require Wazuh to be running already?
Usually the Wazuh deployment comes first, because the SSO work changes the dashboard and indexer configuration of an existing installation. If you already run Wazuh, the scope can focus on Keycloak and the role mapping. If you are still planning the Wazuh deployment, choose the installation method early, since it affects how configuration files are changed and restarted.
Wazuh documents several deployment options, including all-in-one installation, step-by-step installation, Docker, Kubernetes and offline installation. Your choice shapes the change procedure and the test window.
Confirm which Wazuh version you run before scoping. The current release line is 4.14, so check that the single sign-on steps in the documentation match your installed version.
How DeployOpen scopes and delivers Keycloak and Wazuh SSO
DeployOpen plans and delivers Keycloak and Wazuh SSO inside your own infrastructure, starting from the identity design and the Wazuh deployment you already run. Engagements are fixed-scope, so the Keycloak client, role mapping, Wazuh indexer settings and verification steps are agreed in writing before work starts.
How we scope
- Confirm the Wazuh version, deployment method and whether the indexer runs as a single node or cluster.
- Record which Keycloak realm, hostnames and TLS certificates the Wazuh dashboard will use for SAML.
- Agree which Keycloak groups or roles map to Wazuh administrator and read-only backend roles.
- Fix the written scope, deliverables and timeline before any configuration changes begin.
How we build
- Create the Keycloak SAML client for the Wazuh dashboard and configure the Roles mapper for role attributes.
- Configure the Wazuh indexer saml_auth_domain and its SAML settings to match the Keycloak metadata.
- Map Keycloak roles to backend roles so administrator and read-only access follow your access model.
- Test sign-in, sign-out and denied access with named test accounts in a non-production environment first.
How we hand over
- Document the Keycloak client settings, certificates, mapper configuration and Wazuh security configuration changes.
- Provide a verification checklist your team can rerun after Keycloak or Wazuh upgrades.
- Walk through the role mapping logic with the people who will approve access changes.
- Record the rollback steps for the indexer security configuration before production cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Review SAML certificate expiry and metadata changes when Keycloak or Wazuh is upgraded.
- Retest role mapping after Keycloak realm changes, group renames or new Wazuh roles are introduced.
- Ask for the retainer terms and response expectations in writing alongside the fixed-scope quote.
