How Metabase SAML SSO with Keycloak works
SAML single sign-on from Keycloak is supported on Metabase Pro or Enterprise, and it follows Metabase's documented Keycloak SAML client setup. If your team runs self-hosted Metabase and wants staff to sign in with the accounts already managed in your existing Keycloak realm, the work is a trust configuration between two systems rather than a change to how analysts query data. Metabase's pricing page places SSO only in the Pro and Enterprise plans, so the plan decision comes before any integration work starts.
The roles are fixed by the SAML model. Keycloak is the identity provider: it authenticates the user, holds the accounts and groups, and issues a signed assertion. Metabase is the service provider: it trusts that assertion and creates or matches a Metabase user when the assertion arrives. The trust rests on a SAML client in Keycloak with the client ID metabase. Its valid redirect URIs must be the Metabase site URL followed by /*, so the Metabase site URL you configure in Metabase and the value in the Keycloak client must match exactly, including scheme and host. A mismatch is the most common reason a first sign-in attempt fails, and it is worth checking before anything else.
Keycloak is an open source identity and access management server licensed under Apache 2.0, and it is a Cloud Native Computing Foundation incubating project. Keycloak supports SAML 2.0 along with OpenID Connect and OAuth 2.0, so the same realm can serve other applications. DeployOpen implements this integration inside your own infrastructure, meaning the Keycloak realm, the Metabase instance and the signing certificates stay under your control. Confirm with your Keycloak owners which realm will hold the Metabase client and who may change its settings, because that person becomes a dependency for every future Metabase access change.
Before the build, decide three things. First, which Keycloak realm and groups map to Metabase access, since Metabase group membership drives what each user can see. Second, whether your Metabase plan includes the advanced group and attribute sync and SCIM provisioning, which are listed as Pro or Enterprise features in Metabase's people and groups documentation, and whether you need them now or later. Third, which Keycloak release and deployment model your team operates, so the client configuration is tested against the same version you will run in production. Confirm these choices against Metabase's current documentation for your version, because the setup steps are documented by Metabase and may change between releases.
What you need before configuring Metabase SAML with Keycloak
Six prerequisites connect the two systems. Metabase needs a plan that includes SAML, a stable public address and a supported version, while Keycloak needs a running server with a staff realm and a current release. Confirm each item in the change plan so the SAML configuration is tested in a window with the right owners available.
Metabase Pro or Enterprise license
SSO is included only in the Pro and Enterprise plans, so a Metabase Open Source or Starter installation cannot complete this setup. Confirm that your license covers the instance you plan to change and that the plan includes SAML. Pro is listed on Metabase's public pricing page, while Enterprise is priced by quote, so ask your Metabase contact which plan fits your user count and identity requirements.
Keycloak instance and staff realm
You need a running Keycloak server, an admin account that can create clients and mappers, and a realm that holds your staff accounts. Place the Metabase SAML client in the staff realm and keep administration separate. Check that staff users carry the email and name attributes Metabase will read. Keycloak 26.8.1, published 13 October 2026, is the current release. Confirm the version against Metabase's SAML with Keycloak page before the change window, and if you run the Red Hat build of Keycloak, confirm that build too.
Stable public HTTPS URL
The Metabase site URL becomes the base for the SAML redirect URIs, so the hostname must resolve to the instance and stay the same after go-live. Metabase's documented client sets valid redirect URIs to the site URL followed by a wildcard path, so a hostname change later means updating Keycloak as well. Confirm that the certificate chain is trusted by user browsers and the Keycloak server, and that load balancers forward the original host and protocol headers.
Supported Metabase version
Choose a release inside the support window before you configure SAML. Metabase 64 is an LTS release published 16 September 2026 with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026. LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after two months. Check the version support page on the day you plan the change, because an upgrade in the same window adds risk to the SSO test.
PostgreSQL application database
Metabase stores its settings, users and saved content in an application database. The embedded H2 database is meant for demos, and Metabase recommends PostgreSQL for production. If your instance still runs on H2, plan the one-time load-from-h2 move first, run it with the Metabase version that last updated the H2 file, and take a backup before the SSO change. Confirm the PostgreSQL version your Metabase release supports in its application database documentation.
Named owners on each side
Name one person on the Metabase side and one on the Keycloak side who can change settings, read application logs and approve the change window. Each owner should be able to roll back their own part, whether that is the Keycloak client or the Metabase SAML settings. Agree in advance who signs off the test sign-in with a staff account and who holds the break-glass Metabase admin account. Without named owners, a failed login turns into a dispute between two teams.
Why SAML SSO changes the plan you need
Adding SAML sign-in through Keycloak moves a self-hosted Metabase onto a paid plan. Metabase's pricing page places SSO in the Pro and Enterprise plans only, and it places row and column level permissions, multi-tenant data segregation, and usage analytics and auditing in those same two plans. The Open Source edition is free to run, but it does not include SAML. Plan the identity work and the licensing decision together, because a Keycloak client that is configured correctly still will not sign anyone in through SAML on a plan that lacks the feature.
The list prices on Metabase's pricing page are the starting point for a budget. Pro is listed at $575 per month, or $517.50 per month when billed yearly, with the first 10 users included and $12 per month for each additional user. Enterprise is priced by quote, starting at $20,000 per year. Starter does not include SAML, so a Starter subscription does not solve the Keycloak requirement, even though it is a paid plan. Confirm these figures on the pricing page before you take them into a budget, since list prices can change.
Open Source and Starter do support Google sign-in and LDAP, so it is worth knowing what those options cover before you decide. Metabase's documentation lists advanced LDAP group and attribute sync, JWT, OIDC, SAML and SCIM provisioning as Pro or Enterprise features, and it lists Keycloak among its documented SAML setups. If your Keycloak realm is the directory of record, LDAP on a free plan is not a drop-in replacement for SAML. Ask which of your sign-in and group requirements can be met on the plan you are considering and which need the paid tier.
Before you sign anything, ask for a written quote that names your user count, because the Pro total depends on how many users you have beyond the first 10. Ask whether the quote assumes annual or monthly billing, whether the Enterprise quote includes the features your security team needs, and who pays for hosting and upgrades on your side. Keycloak is licensed under Apache 2.0, so the identity server carries no software license fee, but operating it, backing it up and keeping it current are costs your team or a partner will carry.
Configuring the Keycloak SAML client for Metabase in order
This sequence connects a self-hosted Metabase Pro or Enterprise instance to a Keycloak realm through SAML, so people sign in with their Keycloak accounts. Each step closes with a check you can run before moving on. Keep the order: the Metabase site URL must be final before the redirect URI is set, and access should open only after pilot accounts pass every check.
Confirm the final Metabase site URL
The Metabase site URL is the address users open in their browser, and the Keycloak redirect URI is built from it, so this value should not change after setup. Your Metabase administrator confirms the exact URL, including scheme and host, in the admin settings. The platform team confirms that the URL resolves through the load balancer or reverse proxy users will use. Check: open the URL in a private browser window and confirm the Metabase sign-in page loads without a certificate warning. Record the value for the next steps.
Create the SAML client in Keycloak
In the Keycloak admin console, select the target realm, then create a client with the client ID metabase and the SAML protocol. Use the realm that holds the pilot users, and confirm with your identity team that this realm is the one Metabase should trust. Check: the client appears in the realm's client list with the metabase client ID, and its protocol shows SAML.
Set the valid redirect URIs
Open the new client's settings and enter the Metabase site URL from the first step, followed by /*, as the valid redirect URI. Copy the value exactly, without trailing spaces or a different path. Metabase's documented Keycloak setup uses this pattern, so follow that page for any other client settings it lists. Check: save, reload the client settings, and confirm the stored redirect URI matches the site URL plus /* character for character.
Configure SAML settings and export identity details
Set the SAML options described on Metabase's SAML with Keycloak page, and use that page as the reference for field names and certificate handling, since names and options can change between Metabase releases. Export or copy the identity provider details the page asks for, then store them in your approved secrets process and keep them out of shared documents. Check: open the exported details in a text editor and confirm they include the Keycloak realm identifier and the signing certificate the Metabase page describes.
Enter identity details and enable SAML
In Metabase's admin settings, open the SAML authentication section, enter the identity provider details from the previous step using the field names on Metabase's Keycloak page, and enable SAML. SAML requires a Pro or Enterprise plan, so confirm the license is active first. Check: save the settings, confirm the SAML status shows enabled, and confirm the sign-in page offers the SAML option. Keep an admin session open so you can correct a field if needed.
Test with pilot admin and standard accounts
Before opening access, sign in with one pilot admin account and one standard user account, each in a private browser session. For each login, check that the Metabase user record shows the expected name and email, and confirm the admin reaches the admin settings while the standard user does not. Then review the Keycloak event logs for both logins to confirm the SAML events were recorded for the metabase client. Open access only after both accounts pass all three checks.
How Keycloak identity fields map to Metabase accounts
This table compares each identity field Keycloak sends during SAML sign-in with how Metabase uses it to match or create an account, and what to check before you depend on it. Read each row as a question to answer in the Metabase SAML with Keycloak documentation and in a test instance. The main takeaway is that every attribute mapping needs its own check, and group and provisioning behavior depends on a Pro or Enterprise plan.
| Keycloak source | Metabase field or behavior | What to confirm |
|---|---|---|
| User identifier in the SAML assertion | Identifies the person signing in and determines which Metabase account the sign-in is matched to | Which NameID format and attribute the Metabase Keycloak guide expects, and that the value stays stable for each user over time |
| Commonly used to match an existing Metabase account or to create a new one on first sign-in | The exact attribute name in the Metabase documentation, and whether Metabase matches on email or on the identifier | |
| First name | Populates the first name shown on the Metabase account | The exact attribute name, and whether Metabase updates the value on every sign-in or only when the account is created |
| Last name | Populates the last name shown on the Metabase account | The exact attribute name, and whether a changed value in Keycloak appears in Metabase after the next sign-in |
| Group membership (if your organization uses groups) | Advanced group and attribute sync is a Pro or Enterprise feature in Metabase's people and groups documentation | Whether your plan supports group sync from Keycloak, and which Keycloak groups, if any, are sent in the assertion |
| Provisioning and removal of accounts | SCIM provisioning is a separate Pro or Enterprise capability covered on its own page | Whether SAML sign-in alone removes access for leavers, and which SCIM page applies if you need automatic account changes |
| Test account before rollout | Mappings take effect at sign-in, so a first test shows what Metabase stores for each field | Sign in with one test account, check each field on the Metabase profile, change one Keycloak attribute, and sign in again before you widen access |
Keeping Keycloak available for every Metabase sign-in
For SAML users, Keycloak's availability becomes Metabase's sign-in availability. When Keycloak is unreachable, Metabase staff who authenticate through the SAML client cannot sign in, so the identity provider needs its own availability design before Metabase is treated as production-ready. Start by deciding which Keycloak deployment pattern the organization will run and which database sits behind it, because both choices determine how much of an outage the identity layer can absorb.
Keycloak supports several production databases, including PostgreSQL 14 to 18. The default dev-file database is for development only and should not appear in any environment that serves Metabase users. Both supported high availability designs require a synchronously replicated database, so ask the database team to confirm how replication is configured, what happens to writes during a failover, and whether the PostgreSQL version in use falls inside the supported range for the Keycloak release you plan to deploy.
Keycloak documents three high availability architectures. A single cluster can run across availability zones, which suits organizations that want one cluster with zone-level resilience. Multi-cluster deployments (v2) run without an external Infinispan cluster. The multi-cluster v1 model used a separate Infinispan cluster per site, and it is deprecated, so it should not be the basis of a new design. Your choice depends on the number of sites, network latency between them, and how much operational complexity your platform team can support during failover tests.
The Keycloak Operator is the recommended installation method when Keycloak runs on Kubernetes, and it is installed through Operator Lifecycle Manager. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Use that mode so each Keycloak change is reviewed, tested against a staging realm and scheduled. Keycloak also migrates its database schema automatically at startup by default, and the upgrading guide suggests manual migration for large deployments, so decide which path applies before the first upgrade.
Keep the local Metabase admin account as a documented break-glass path for the period when Keycloak is unavailable. DeployOpen can design that path, including the runbook, the conditions for using it and the logging expected afterward. The client must decide who holds the credentials, how they are stored, who can approve their use and how often the account is tested. Those ownership decisions belong to your security and operations leaders, and they should be recorded before go-live rather than during an outage.
Securing the SAML trust between Keycloak and Metabase
Keycloak issues the SAML assertions that Metabase accepts, so a loose client definition, a weak admin account or an unmanaged certificate can grant access to analytics data. The cards below cover the client, its redirect URIs, administrator access, signing material, event review and Metabase admin rights. Check each control in your own environment before go-live and after every change.
Limit the client to users who need it
Keycloak issues a SAML assertion only to a user who authenticates in the realm, so the realm user pool and any role or group mapping that feeds the metabase client decide who reaches Metabase. Scope the client to the realm and the groups that need analytics access, and remove users who have no analytics role. Export the list of users who can sign in through the client and compare it with the people your data owners have approved. Confirm in your Keycloak version which roles are mapped into the assertion.
Keep redirect URIs narrow and HTTPS
Metabase's documented Keycloak setup sets the valid redirect URI to the Metabase site URL followed by a wildcard path. Use the exact HTTPS site URL configured in Metabase, and avoid wildcard hostnames, plain HTTP addresses and leftover test or staging entries. Keycloak sends the browser back to a matching URI with the signed response, so every extra entry widens where that response can go. Review the list whenever a hostname changes or an environment is retired.
Protect Keycloak administrator access
Keycloak administrators can change the metabase client, its redirect URIs and its signing keys, which makes the admin console the most sensitive login in this trust. Require multifactor authentication for every administrator, use personal admin accounts, and limit client editing to a small team through the realm's admin roles. If you deploy Keycloak with the Operator, manage KeycloakSAMLClient resources through the same review and change record as manual edits.
Track signing certificate and metadata
Metabase trusts the signing certificate that Keycloak publishes in its SAML metadata, so an expired certificate breaks sign-in and an unrecorded change can hide a swapped key. Record who imports or rotates the signing material, when it changes, and when the new metadata is loaded in Metabase. Before the current certificate expires, rehearse the rotation in both products and confirm sign-in with a test account. Keep the steps in a runbook that your team can follow without the original author.
Monitor login and admin events
Keycloak can record login and admin events, and those records show failed sign-ins, changes to the metabase client and administrator actions. Turn on event logging for the realm and route the events to the place your security team reviews. Alert on changes to the client, its redirect URIs and its certificates, and set retention to match your own policy. Confirm the event types, storage path and retention options against the documentation for your Keycloak version.
Keep Metabase admin rights small
Metabase administrators can change database connections, permissions and user accounts, so SAML sign-in should not make admin status easy to acquire. Keep the admin group small and named, and have each member sign in with an individual account. SSO is available only on Metabase Pro and Enterprise, so confirm which group or attribute mappings your plan supports before you depend on them. Review admin membership on a fixed schedule and remove access when someone changes role.
Why Metabase SAML login with Keycloak fails and how to fix it
This table matches each common Metabase and Keycloak SAML sign-in failure with its likely cause and the check that confirms it. Work down the rows in order, because the plan check and redirect settings rule out the most common causes before you review certificates, users and infrastructure. Test every fix with a single account before you widen access again.
| Symptom | Likely cause | Fix and check |
|---|---|---|
| Redirect error or invalid redirect URI on sign-in | The Metabase site URL changed after the Keycloak client was created | Compare the client's valid redirect URIs with the current site URL followed by /* and update both to match. |
| Keycloak rejects the SAML request | The SAML client ID is not metabase | Open the Keycloak client list and confirm the client ID is exactly metabase, as in Metabase's documented Keycloak setup. |
| No SAML option in Metabase admin settings | The instance runs Open Source or Starter, where SSO is not included | Confirm the plan under Metabase admin. SAML needs Pro or Enterprise, so verify the license before changing Keycloak. |
| Login works but the user lands in the wrong account or a new account is created | The SAML assertion has no email attribute, so the Metabase account does not match | Review the client mappers in Keycloak and confirm an email attribute is sent in the assertion. Test with one account. |
| Signature or certificate validation fails after a Keycloak change | The Keycloak certificate or metadata was rotated and Metabase still holds the old material | Download the current Keycloak metadata, reload it in Metabase and compare the certificate details with the Keycloak realm keys. |
| One user cannot sign in while others can | The user is disabled or is not in the Keycloak realm | Check the user's enabled status and realm membership in Keycloak, then review that user's login events in the event logs. |
| Browser is sent to an HTTP address or the login loops | A load balancer or proxy changes the scheme, so the redirect uses HTTP | Confirm the Metabase site URL uses HTTPS and the proxy passes the original scheme. Compare the redirect URL in a browser trace. |
| Sign-in fails only on some nodes or sites | Keycloak runs in a multi-site design without a synchronously replicated database | Keycloak's supported high availability designs require synchronous database replication. Verify replication mode and review event logs per site. |
| Sign-in breaks after an upgrade | A Metabase or Keycloak upgrade changed behavior | Read the release notes for both products, repeat the test on a staging copy with one account, and keep the pre-upgrade backup for rollback. |
Upgrading Metabase and Keycloak without locking people out
Upgrade the two sides one at a time and confirm SAML sign-in after each step, so that a failure points to one component. The main risk is not the upgrade itself but an intermediate state where Metabase and Keycloak disagree about the SAML client, the redirect URIs or the users they expect to sign in. Rehearse the full sequence in a staging copy that matches production in its SAML client settings, its Metabase site URL and its database engine. Record the Keycloak version, the Metabase version, the application database version and the date before each step. If staging differs from production in any of these areas, fix the difference before you rehearse the change window.
For Metabase, start with a verified backup of the application database. Metabase's upgrade documentation recommends this step, and the same backup is the preferred rollback path. If the deployment runs as a cluster, reduce it to a single node for a major upgrade, because the documentation identifies a migration lock during that step. If the installed version is older than release 40, upgrade one release at a time instead of jumping to the latest version. Check the target against the version support page before you start. LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after 2 months. A deployment on a non-LTS release will need another upgrade soon after the next release ships, so confirm which release your team is targeting and when it ends support.
Keycloak follows a different pattern. The project plans four minor releases a year, and since Keycloak 26.0 it has said that breaking changes in a minor release will be opt-in, so a minor upgrade should not change behavior until your team enables the relevant option. Read the release notes and the upgrading guide for every minor release between your current version and the target, because opt-in changes still need a decision. By default, the database schema migrates automatically at startup. For large deployments, the upgrading guide suggests manual migration, in which administrators apply the SQL themselves and review it before the new server starts. Decide which mode you will use before the change window, and take a database backup immediately beforehand.
Test the SAML login after each upgrade on both sides. After the Metabase upgrade, sign in through Keycloak with a standard user, a group member who should have access, and an account that should be denied. After the Keycloak upgrade, repeat those checks and confirm that the Metabase SAML client still receives the same attributes and group mappings. Keep the test accounts and expected results in the change record so the same checks run after every upgrade. Write the rollback plan before the window opens. For Metabase, the recommended rollback is restoring the pre-upgrade application database backup, and running the migrate down command with the newer JAR is the other documented option. For Keycloak, name the database backup and the previous server package or image that will be restored, and name the person who decides to roll back and the criteria they use to make that call.
Questions buyers ask about Metabase Keycloak SAML SSO
Does SAML SSO work on Metabase Open Source or Starter?
No. According to Metabase's pricing page, SSO is included only in the Pro and Enterprise plans, so Open Source and Starter cannot sign users in through SAML with Keycloak. Confirm the plan features on the pricing page before you buy, because plan contents can change. If your instance runs Open Source or Starter, you have two paths: upgrade to Pro or Enterprise, or use a sign-in method those plans support, such as Google sign-in or LDAP. The Keycloak SAML design can still be documented now so the upgrade is ready when you make it. A partner can confirm which plan your user base needs before any license is purchased, which keeps the upgrade decision tied to your actual requirements.
How much does the Metabase Pro plan cost for SSO?
According to Metabase's pricing page, Pro lists at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Additional Pro users cost $12 per month each. Enterprise is priced by quote, starting at $20,000 per year. The total depends on the plan, the user count and the billing period. Illustratively, 15 users on monthly Pro would be $575 plus five extra users at $12 each, or $635 per month, before tax or other billing terms. Ask Metabase for the yearly add-on rate and any Enterprise features you need. DeployOpen's implementation fee is a separate cost, set by the written scope, so request both figures side by side.
How long does Keycloak SAML SSO setup for Metabase take?
No fixed duration can be given until the scope is known. The effort depends mainly on your identity model, meaning how users, groups and attributes are organized in Keycloak, and on how many realms are involved. A highly available Keycloak design adds planning and testing, and Keycloak's supported high availability architectures require a synchronously replicated database. Validation with test users and the change windows your organization requires often set the calendar more than the configuration does. Ask for a timeline that lists each phase: discovery, Keycloak configuration, Metabase configuration, test group validation and cutover. Also ask which phases sit inside the fixed scope and which depend on your change calendar.
What does our team need to provide for a SAML SSO project?
Four roles are needed. First, a Keycloak administrator who can create and change the SAML client, realms and group mappings. Second, a Metabase administrator who can configure SAML sign-in and manage groups in Metabase's admin settings. Third, a named owner for the SAML signing certificates and their renewal, so an expiry does not interrupt sign-in. Fourth, a test group of users who can check sign-in, group membership and permissions before the change reaches everyone. You also need a non-production Metabase and Keycloak environment, or an agreed way to test safely. Confirm these owners early, because a missing certificate owner or test group can stall the project at the validation stage.
Can our own team configure Metabase SAML with Keycloak?
Yes, if your team already has Keycloak and Metabase administration skills and a test environment. The configuration follows Metabase's documented Keycloak setup: create a SAML client with the client ID metabase in Keycloak, set the valid redirect URIs to the Metabase site URL followed by /*, then configure SAML in Metabase. The core steps are documented, so most of the difficulty sits in the surrounding decisions: group mapping, role design, certificate handling and test coverage. A partner adds the most value where the team has not done this before, where several Keycloak realms are involved, or where the change must be reviewed against internal controls. DeployOpen can plan and implement the setup, but your team can also do it alone if these skills and an environment are in place.
What can open source Metabase users use instead of SAML?
On Open Source and Starter, Metabase supports Google sign-in and LDAP. Advanced LDAP group and attribute sync, JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. LDAP on the lower plans therefore gives directory-based sign-in without the advanced group sync. If your users are in Keycloak, confirm whether an LDAP route is available to you before choosing it, because it does not provide the SAML flow. Many teams keep SAML as a planned upgrade: they decide on Pro or Enterprise later, while the Keycloak client design, group names and test plan are documented now. The later switch then involves configuration, and the design work is already done.
What does a fixed-scope SAML SSO engagement cover?
A fixed-scope engagement covers the work listed in a written scope, with deliverables and timelines agreed before work starts. For this topic, that typically means reviewing your identity model, configuring the Keycloak SAML client to Metabase's documented setup, configuring SAML in Metabase, validating sign-in and group mapping with a test group, documenting the settings and handing over operating steps. The scope should name the Keycloak realms, the Metabase instance, the environments and the test cases. Ongoing support, upgrades and continuous testing can be added as a retainer. DeployOpen does not issue audit reports or certifications. If the SSO design must support an assessment, ask what evidence the engagement produces, then let the assessor decide what it accepts. Request the quote against the written scope.
What redirect URI does a Metabase Keycloak SAML client need?
The Keycloak SAML client for Metabase uses the client ID metabase, and its valid redirect URIs are set to your Metabase site URL followed by /*. Illustratively, if the site URL were metabase.example.internal, the redirect URI would be that address followed by /*. Two checks help avoid mismatches. First, the site URL in Metabase's admin settings must match the public address users type, including the scheme and any port. Second, the redirect URI in Keycloak must use the same host, so any change to the address requires updating both sides. Confirm the exact SAML settings against Metabase's current Keycloak documentation before you change production.
How DeployOpen works on this
DeployOpen scopes Metabase and Keycloak SAML SSO as a fixed-scope engagement, with the written scope fixing which Metabase edition, Keycloak environment and sign-in paths are covered. We build the connection in your infrastructure, follow Metabase's documented Keycloak setup, and hand over tested configuration and runbooks. Ongoing support is available as a retainer.
How we scope
- Confirm the Metabase edition and plan that includes SSO, since SAML requires Pro or Enterprise.
- Record the Keycloak realm, version, hostnames and TLS setup that the Metabase client will use.
- Define which user attributes, groups and fallback sign-in paths are in scope, with named owners.
How we build
- Configure the Keycloak SAML client ID metabase with redirect URIs set to the Metabase site URL plus /*.
- Map SAML attributes and Metabase group membership, then test sign-in with accounts from each target group.
- Harden the setup with documented settings in your own environment, and check login, logout and session behavior.
How we hand over
- Deliver the exported Keycloak client configuration, Metabase SSO settings and a record of each change made.
- Provide a test script and results covering sign-in, group mapping and denial for users without access.
- Document the runbook for rotating the SAML signing certificate and updating redirect URIs after a URL change.
How we support
- Track Keycloak release changes, since minor releases are planned four times a year and need review.
- Review Metabase upgrades in a test copy first, with the application database backed up before each change.
- Offer ongoing support as a retainer covering SSO configuration changes, reviews and recovery steps.
