Metabase SSO and identity integration guide

Which Metabase SSO method fits your identity stack

The SSO method you can use depends on your Metabase edition. On Open Source and Starter, the built-in options are Google sign-in and LDAP. JWT, OIDC, SAML, advanced LDAP group and attribute sync, and SCIM provisioning require Pro or Enterprise, because SSO is a paid-plan feature and is not included in Open Source or Starter. Before choosing a method, confirm which edition you will run, since that decision narrows the options more than any technical preference. The harder part of this work is not the login itself. Once a user can sign in, Metabase still has to decide what that user can see. Group membership from your identity provider has to map to Metabase groups, and those groups drive data access, collection permissions and admin rights. Attributes such as department or region may also feed row-level or column-level rules on Pro and Enterprise. A login that works but maps every user into a broad default group will pass a quick test and then expose the wrong data. Plan the group design and the mapping rules as a deliverable in their own right, and test them with real accounts from each team. Local accounts are the second source of risk. Most self-hosted Metabase instances already have users created by hand, sometimes including shared or service accounts with admin rights. Decide early whether those accounts are migrated to SSO by matching email addresses, disabled after cutover, or kept as break-glass administrators. Each choice has a different effect on audit history and on who can still sign in if the identity provider is unavailable. Write the cutover sequence down: when users are switched, how passwords are retired, and who approves the removal of local admins. To narrow the choice, list the identity provider you run (Google Workspace, Entra ID, Okta, Keycloak, Auth0 or an on-premises LDAP directory), whether you need group sync or only sign-in, and whether you require automated deprovisioning through SCIM. Then confirm with Metabase which features your chosen plan provides for that provider, because setup guidance and supported options differ by edition and by version. Ask your identity team who owns group membership, how often it changes and whether group names are stable enough to use as mapping keys.

Pilot the chosen method with a small group before cutover, and record which users, groups and permissions were produced by the mapping. Keep at least one local administrator account documented and tested, so that an identity outage does not lock out the team that maintains the instance.

Components and settings involved in Metabase identity

Metabase SSO touches more than one place. Authentication settings, group mappings, user attributes, the application database and the identity provider's client registration all have to agree before a single sign-on login behaves as intended. Review each component below before you configure anything.

Authentication provider settings in the admin console

Metabase authentication providers are configured in the admin console, which is where you enable Google sign-in, LDAP, or, on Pro and Enterprise, JWT, OIDC or SAML. Confirm which methods your plan includes before you plan the rollout, since SAML, OIDC and JWT require Pro or Enterprise. Check how the setting behaves for users who already exist with a password, and decide whether password login stays available as a fallback for administrators.

Group mappings to permission groups

Group mapping connects groups in your identity provider or directory to Metabase permission groups, so access follows directory membership rather than manual assignment. Advanced LDAP group sync and SCIM provisioning sit on Pro or Enterprise. Map each external group to exactly one purpose, document which Metabase groups are granted by mapping and which are managed by hand, and test that removing a user from a directory group also removes the Metabase access they gained through it.

User attributes used for sandboxing

User attributes passed from your identity provider, such as a region, business unit or tenant identifier, feed the data sandboxing rules that restrict which rows a user can query. These attributes are only as reliable as the claims or directory fields that populate them. Confirm the attribute names with your identity team, check that they update when a person changes roles, and verify sandboxed results with test accounts from each segment before launch.

Application database storing users and groups

Metabase stores users, groups, sessions and settings in its application database, which is H2 by default for demos and PostgreSQL in production. Identity state lives here, so the database needs the same backup, access control and upgrade planning as the rest of the deployment. If you later move off H2 with the load-from-h2 command, run it with the Metabase version that last updated the H2 file and verify that users and group memberships survived the move.

Identity provider application or client registration

Each identity provider needs an application or client registration that names the Metabase URL as an allowed redirect or callback target. The registration defines the client identifier and secret, the scopes or claims released, and which users or groups may sign in. Record who owns this registration, where the secret is stored, and when it expires, because a mismatch in the redirect URL or a missing claim is the most common reason sign-in fails after go-live.

Backend environment variables and version checks

The Metabase backend runs as a JAR, and some identity-related settings are supplied as environment variables rather than through the admin console. Because option names and behavior can change between releases, confirm each variable against the documentation for the exact version you run, including any LTS release you plan to stay on. Keep the variable list in version control with the deployment, so an upgrade does not silently drop an identity setting.

Choosing between Google, LDAP, SAML, OIDC, JWT and SCIM

This table compares the Metabase sign-in and provisioning methods by edition, identity provider input, group and attribute sync, and ongoing operating cost. Read each row against your identity provider and your edition, because the plan you already pay for decides which methods are available before any technical question comes up. The main takeaway is that the cheapest-looking method on the free edition still needs a plan for group access and offboarding.

Method	Edition required	What it needs from the identity provider	Ongoing operating cost
Google sign-in	Open Source or Starter	Google Workspace domain and OAuth client; no group sync	Low. Confirm domain restrictions and who can create the OAuth client.
LDAP (basic)	Open Source or Starter	Directory bind account, search base and user filter	Moderate. The bind account password needs rotation and a plan for expiry.
LDAP with group and attribute sync	Pro or Enterprise	Directory group membership and attributes exposed to the bind account	Moderate. Group mappings must be reviewed when directory groups change.
SAML	Pro or Enterprise	Signing certificate, entity metadata, and attribute or group claims	Higher. Certificate rotation and metadata updates must be scheduled and tested.
OIDC	Pro or Enterprise	Client registration, redirect URI, and group or role claims in the token	Moderate. Client secret rotation and token claim changes need change control.
JWT	Pro or Enterprise	Shared signing key and a token issuer that your team controls	Higher. Your team owns key management and the token issuing service.
SCIM provisioning	Pro or Enterprise	SCIM endpoint and token from the identity provider, with a supported connector	Moderate. Ongoing provisioning lifecycle checks, plus token renewal.

How to build Metabase SSO step by step

This sequence moves a Metabase instance from local accounts to single sign-on with group-based permissions. Each step ends with a check, so a fault surfaces with a small pilot group before it affects every user. The output is a tested sign-in path, mapped groups and attributes, and a documented cutover from local accounts.

Confirm the edition and application database
Confirm that your plan includes the identity option you need. Google sign-in and LDAP are available on Open Source and Starter, while SAML, OIDC, JWT, advanced group and attribute sync, and SCIM require Pro or Enterprise. Next, check which application database the instance uses. The embedded H2 database is intended for demos, and PostgreSQL is the recommended production choice, so plan the move before users depend on the instance. Record the Metabase version and database engine in the change record. Done when a named owner has written down the edition, the current database engine, the target database, and the plan details confirmed against the vendor's pricing page.
Register Metabase with your identity provider
Create an application registration in the identity provider that follows the documented setup for your provider, such as Entra ID, Okta, Keycloak or Google. Use the Metabase documentation to find the exact callback address, the sign-on method, and the claims or attributes the provider must send. Store the client secret in your secrets manager and limit who can edit the registration. Done when the registration exists in a non-production tenant or realm, the callback address points to your Metabase URL over HTTPS, and an identity administrator has reviewed which claims are released.
Configure the provider in Metabase
In the Metabase admin settings, enable the authentication method that matches the registration. Enter the values the provider issued, such as the issuer URL, client ID and client secret. Keep local login enabled during this step so an administrator can still sign in if the configuration fails. Confirm that the instance's public address matches the one registered with the provider, because a mismatch is a common cause of failed sign-in. Done when an existing Metabase administrator completes a sign-in through the provider in a private browser session, and the account Metabase creates or matches is the expected one.
Test sign-in with a pilot group
Assign a small pilot group in the identity provider with a mix of roles, such as an administrator, a power user and a viewer. Ask each person to sign in, open a saved question and a dashboard they should see, and try one they should be denied. Record what each user sees, including the account name and email that Metabase stored. Correct any claim or attribute mismatches before you expand the group. Done when every pilot user signs in through the provider, sees the expected content, and is denied content outside their access.
Map identity provider groups to permission groups
Create or choose the Metabase permission groups that match your access model. Then map each identity provider group to the Metabase group it should populate, using the group sync setting described in the Metabase documentation. Group and attribute sync require a Pro or Enterprise plan, so confirm this before you start. Keep administrator membership as small as possible and review group names with the data owners. Done when a test user's Metabase group memberships change when the provider group changes, and each group's data permissions match the access matrix approved by the data owners.
Set user attributes for data access
Decide which user attributes, such as region, business unit or tenant, should drive segmented access. Confirm that the provider sends them as claims or attributes, then map each one in Metabase so it is available to permission rules and any database-level filtering. Row and column level permissions and multi-tenant segregation are Pro or Enterprise features, so verify your plan first. Done when a test user with a known attribute value sees only the rows that value allows, and a second test user with a different value gets a different result for the same question.
Enable SCIM only after sign-in is stable
Turn on SCIM provisioning only after pilot sign-in and group mapping have worked through a full test cycle. Otherwise, provisioning changes can mask a configuration problem. Configure the provider's SCIM connector with the Metabase endpoint and token, and scope it to the pilot groups first. Compare the accounts that are created, updated or disabled with the provider's activity logs. Done when a change made in the provider appears in Metabase, and a disabled test user can no longer sign in.
Cut over from local accounts
Announce a cutover date, then move the remaining users to SSO. Restrict local password logins to a small set of break-glass administrators whose credentials are held in a sealed store. Confirm that each active local account has a matching identity provider account, then archive or disable the others according to your retention rules. Keep a tested recovery path and document who may use it. Done when all standard users sign in through the provider, the break-glass accounts have been tested once in a controlled exercise, and the change record shows who approved the cutover.

What drives SSO effort and how to reduce it

This table lists the factors that change how much work a Metabase SSO integration takes, with a way to keep each one contained. Read each row as a lever: the driver on the left, why it matters in the middle, and the practice that keeps it manageable on the right. The main takeaway is that a clean identity provider group model and a single-group pilot usually matter more to effort than the raw user count.

Driver	Why it changes effort	How to keep it down
User count	Provisioning, first-login behavior and access reviews scale with the number of people who sign in, especially if SCIM is used to create and deactivate accounts.	Confirm which user population needs Metabase access before scoping. Pilot with one team, then expand in waves.
Identity sources	Each identity provider or LDAP directory needs its own configuration, testing and failure handling. Users present in more than one source create matching questions.	Use one authoritative identity source for Metabase login. Confirm whether Google sign-in or LDAP is in scope on the free edition before adding others.
Group count and nesting	Every group mapped to a Metabase permission group must be designed, tested and maintained. Nested groups in the identity provider can produce unexpected memberships in Metabase.	Map a small set of groups that already reflect data access roles. Flatten nesting where possible and document which group grants which Metabase permission.
Attributes for row-level security	Row-level permissions depend on user attributes passed from the identity provider. Missing, inconsistent or multi-valued attributes cause incorrect data visibility or login problems.	Define the attribute names and value formats in the identity provider first. Confirm with the vendor which attribute sync options your plan includes, then test with sample users.
Environments (dev, staging, production)	Each environment needs its own identity provider application or client registration, redirect URLs and test users. Settings copied between them often drift.	Keep the configuration in a documented checklist. Test sign-in and group mapping in staging with representative accounts before changing production.
Compliance evidence requests	Assessors may ask for records of who can sign in, how access is granted and removed, and how mappings are changed. Gathering this after the fact takes significant effort.	Agree the evidence list before build. Record group mapping changes, access reviews and SSO configuration exports as part of normal operations. Ask your auditor which artifacts they expect.
Plan and feature availability	SAML, OIDC, JWT, advanced group sync and SCIM require a paid plan. Choosing the wrong edition late in the project forces rework.	Confirm the edition and required features in writing before scoping. Check the current pricing page, since plan limits and availability can change.

SSO differences across deployment models

A single Metabase instance is the simplest case for SSO. The identity provider redirects users back to one site URL, and the instance sets its own session cookie for that host. Most early problems come from the public site URL in Metabase's admin settings not matching the address users actually type, which breaks the return redirect after sign-in.

What to check on a single node:

Site URL: the external URL in admin settings must match the scheme, host and port that users and the identity provider use.
Callback or ACS address: register the exact callback address your Metabase version expects with the identity provider.
Cookie settings: confirm the session cookie is marked secure when served over HTTPS and that the browser keeps it.
Clock and certificate validity: SAML assertions and token signing keys fail quietly when server time drifts or a certificate expires.
Group claims: test that a sample user's group membership arrives in the token or assertion in the format your Metabase version maps.

Confirm each of these settings against the Metabase version you deploy, because callback paths and admin labels change between releases.

Hardening access through identity

Once Metabase trusts your identity provider, the security of analytics depends on how that provider is configured and who can reach Metabase through it. The cards below cover the identity-side and Metabase-side decisions that decide whether single sign-on actually narrows access.

Least-privilege IdP app assignments

Assign the Metabase application in your identity provider only to users and groups who need analytics access, rather than to the whole directory. Confirm that unassigned users cannot complete sign-in, and test with an account outside the assigned groups. Review assignments on a fixed schedule, because contractors and leavers often keep access through forgotten group memberships.

Protecting the LDAP bind account

On LDAP setups, Metabase uses a bind account to search the directory for users and groups. Give this account read-only access to the search base it needs, store its password in a secrets manager, and rotate it on a schedule your directory team can support. Confirm that the account cannot write to the directory and that its login events are logged.

Certificate and client secret handling

SAML signing certificates, OIDC client secrets and LDAP certificates all expire or need replacement. Record each credential's owner and expiry date, keep secrets out of configuration files and version control, and plan the rotation window with the identity team. Test a rotation in a staging instance first, since an expired certificate typically blocks every login at once.

Disabling local password login after cutover

Local Metabase accounts with passwords remain usable after SSO is live unless you turn that path off or remove those accounts. Before cutover, list every local account, including service and former staff accounts, and decide which must stay. Keep one documented break-glass admin path for identity outages, and confirm that it is tested and stored securely.

Session lifetimes and re-authentication

Session length determines how long a stolen browser session stays valid after an employee leaves or a device is lost. Agree on session lifetime with your security team, and check how Metabase sessions interact with the identity provider's own session and sign-out settings. Confirm that disabling a user at the IdP ends their Metabase access in a time your policy accepts, and test it.

MFA enforced at the identity provider

Metabase does not add its own second factor, so multi-factor authentication depends on the policies in your identity provider. Enforce MFA for the Metabase application through a conditional access or sign-on policy, and check which authentication methods are allowed for it. Confirm the policy applies to every sign-in route, including mobile and API-adjacent access you have approved.

Keeping admin rights in a small mapped group

Map only a small, named group from your identity provider to Metabase administrator rights, and keep that group's membership under change control. Avoid mapping broad groups to admin, and review admin membership on a schedule. Confirm which group mappings are available on your Metabase plan, since advanced group sync requires Pro or Enterprise.

How to test SSO and confirm it fails safely

Test SSO before any business user depends on it, and treat each case as a pass or fail with evidence attached. Run the cases against a staging instance that uses the same identity provider tenant, group mapping and Metabase version as production, with test accounts placed in each group the design relies on. Record the expected result before each run so that an unexpected outcome cannot be explained away afterward. Schedule the work so that a failed case can be fixed and re-run without disrupting users. The cases below cover the failure modes that matter most for this integration: access for new users, blocked removals, empty group membership, permission revocation, recovery when the identity provider is misconfigured, and attribute-driven data restrictions.

Start with the access cases. A new user in a mapped group should sign in through the identity provider, get a Metabase account created on first login, and receive only the permissions tied to that group. Next, disable the test user in the identity provider and confirm that the next sign-in attempt fails and that any existing Metabase session stops working within the session lifetime your team has agreed. Then sign in as a user who belongs to the identity provider application but to none of the mapped groups. Confirm whether that user is rejected outright or admitted with no permissions, and check that neither outcome exposes protected collections or data. Defaults vary by configuration, so verify the behavior you actually get rather than assuming it matches policy.

Next, test revocation. Remove the test user from a group that grants access to a collection, then check whether the permission disappears at the next login or at the next group sync, depending on how your Pro or Enterprise sync is configured. Record the time of the removal and the time the permission is gone, so the lag is documented. For the lockout case, simulate a broken identity provider setting on staging and confirm that a retained local administrator account can still sign in and correct it. Keep that account's credentials in a sealed store, verify that the password works, and document who may use it and under what approval. A recovery path that has never been exercised cannot be relied on, so run this test before go-live and again after each change to the identity configuration.

Test attributes against the data, not only the login screen. If your design uses user attributes to restrict rows or columns through sandboxing, which is included in Pro and Enterprise, sign in as one test user per attribute value and query the same table. Confirm that each user sees only the rows their value allows, and that a missing or empty attribute produces the most restrictive result your policy requires, with no broad access. Check how the value is formatted, including letter case, leading or trailing spaces and multiple values, because identity providers often send these differently from what the team expects. Repeat the check after any sync that changes an attribute.

Log what proves each case. For every test, capture the identity provider sign-in event, the Metabase login or failure entry, the group membership before and after the change, and the query result for each attribute test. In Metabase, review the application log output from the process that runs the JAR, along with the people, groups and permissions admin views, which show the state after each change. If your Pro or Enterprise plan includes the audit and usage analytics features, use them to confirm which user viewed which content. Check the Metabase and identity provider documentation for where each log is written and how long it is kept in your environment, since both depend on your hosting and log pipeline. Store the results with the test date, Metabase version and configuration version so that an independent assessor can trace each result.

Operating SSO after go-live

This table lists the recurring tasks that keep Metabase single sign-on working after go-live, what each involves, and where teams usually slip. Read it as an operating checklist and assign an owner to each row before launch. Most SSO breakage traces to expired credentials and untested upgrades, and the version support page lists Metabase 64 LTS end of life as 1 December 2027.

Task	What it involves	Where it usually fails
Failed logins and sync errors	Review Metabase logs and identity provider sign-in logs for failed logins and group sync errors.	Alerts are not configured, so failures surface only when users report them.
Certificate and bind password rotation	Track SAML certificate expiry in the identity provider and rotate the LDAP bind password on a set schedule.	The certificate is renewed in the identity provider but Metabase is not updated, so sign-ins fail at expiry.
Quarterly group membership review	Compare directory groups with Metabase group mappings, then remove leavers and unused mappings and record sign-off.	Mappings from the pilot remain, so former project members keep access.
Application database backup	Back up and verify the application database before every upgrade, since migrations run automatically at startup.	Only the JAR and config are backed up, so users, groups and SSO settings cannot be restored.
SSO retest after each upgrade	Repeat test sign-ins for each login method, group mapping and user attribute on a staging copy first.	Testing covers the login page only, so broken group mappings reach users unnoticed.
IdP mapping documentation	Record identity provider application settings, claim and attribute names, group mappings and an owner for each.	The record is written at go-live and not updated after identity provider or group changes.
Version support window	LTS releases are supported for 14 months, and every release gets security fixes until end of life.	Teams stay on an old release past end of life because no one owns the upgrade.

What changes for users and administrators at cutover

The first decision at cutover is what happens to existing local Metabase accounts. Before switching on SSO, export the list of local users and compare each email address with the identity provider (IdP) directory. Then assign every account one outcome: it links to the IdP identity, it is deactivated, or it is kept as a named break-glass administrator. Metabase matches users by email address, so case differences, aliases or retired addresses can produce a second account for the same person. Confirm with your Metabase version how an SSO login is matched to an existing local account with the same email, and test that case, a mixed-case address and a changed address before any user signs in.

Users will notice a change on the sign-in page. Confirm whether the email and password form stays visible beside the SSO button for your edition and configuration, and whether old bookmarks, links in emails and chat messages, and links to embedded dashboards still resolve. Tell users which address to use, which button to press, and what to expect on their first login through the IdP. Also confirm whether existing API keys and any service accounts that call the Metabase API continue to work after SSO is enabled. Those integrations are often missed in the cutover plan and fail without warning.

Password resets change for anyone who signs in through the IdP. In that case, the IdP should own password reset, lockout and multi-factor authentication, and users should be told not to set or reset a password inside Metabase expecting it to apply. Confirm whether Metabase still sends reset emails to SSO users, and whether those emails can be suppressed or pointed to the IdP's reset page. Local password users, including the break-glass account, keep a separate password policy and reset path, so the team must document who controls each one.

Administrators must reconfirm several settings after the first real logins. Check that the admin flag and group memberships are assigned as intended for each mapped group, that the default group is not granting broader access than planned, and that collection permissions still match the permissions model. Confirm how removed or disabled IdP users are deprovisioned, since this depends on whether SCIM is in use or whether accounts are deactivated manually. Write the fallback path before cutover: name the break-glass administrator, store its credentials in the team's secrets manager, test a local login, publish a short message that says what users do if the IdP is unavailable, and state how long local login stays available.

Questions teams ask before SSO work

Is Google sign-in or LDAP enough for Metabase SSO on the open source edition?

Google sign-in or LDAP can be enough on the open source edition if they cover your login and permission needs. Metabase's people and groups documentation lists both as supported on the open source and Starter plans. Google sign-in suits teams that only need company accounts to log in. LDAP suits teams whose directory already holds the users, but advanced LDAP group and attribute sync requires Pro or Enterprise. Ask your identity team three things: which directory groups must drive Metabase permissions, whether user attributes must reach queries, and whether access must be removed automatically when someone leaves. If any answer is yes, plan for a paid plan before you commit to a method.

Why does SAML for Metabase require a Pro or Enterprise plan?

SAML requires Pro or Enterprise because Metabase places SSO in those plans. Metabase's pricing page lists SSO, row and column level permissions, multi-tenant data segregation, and usage analytics and auditing as included only in Pro and Enterprise. Metabase's people and groups documentation also lists SAML, along with JWT, OIDC, advanced LDAP group sync and SCIM provisioning, as requiring those plans. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month. Enterprise is priced by quote starting at $20,000 per year. Check the current figures on Metabase's pricing page before budgeting, because list prices change.

What does a Metabase SSO project need from our identity provider team?

The project needs an identity provider administrator who can create and configure a Metabase application, define the claims or assertions Metabase reads, and set the redirect and logout addresses for each environment. Your identity team should also decide which groups or attributes map to Metabase permissions, who approves the mapping, and who owns the signing certificate or client secret and its renewal date. If SCIM provisioning is in scope, they must confirm how accounts are created, updated and disabled. Plan for test accounts in a non-production identity tenant, and a named contact who can answer questions during testing. Metabase's documentation includes setup guides for Auth0, Entra ID, Google, Keycloak and Okta, so confirm which of these matches your provider before the work starts.

Can our own engineers set up Metabase SSO without outside help?

Your engineers can set up Metabase SSO themselves if they have configured SAML or OIDC against your identity provider before and can run a staging Metabase instance. The hard parts are rarely the Metabase settings. They are usually group design, mapping claims to the right permissions, testing sign-in and sign-out, handling users who change roles, and keeping a fallback administrator who can still log in if SSO fails. Ask whether your team has time to test these cases across every environment and whether someone will own the configuration after go-live. DeployOpen plans, implements and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and can take the work fixed-scope or support it through a retainer.

How long does Metabase SSO take, and what changes the timeline?

No single duration applies to every Metabase SSO project, so ask for a timeline in the written scope rather than relying on a general estimate. The main drivers are the number of groups that must map to permissions, how many attributes must reach queries, and how many environments need SSO, such as staging, production and any embedded analytics. Whether SCIM provisioning is included, how many identity providers or applications exist, and how quickly your identity team can review configuration and test results also matter. Scope changes after signing usually add time, so agree on the group-to-permission matrix and the environment list early. Confirm the expected test window and cutover approach with the team that will sign off.

What should we ask for in a fixed-scope quote for Metabase SSO?

Ask for a written scope that names the sign-in method, the Metabase plan it assumes, and the identity provider and protocol involved. The quote should list each environment, the group-to-permission mapping and attribute mapping to be delivered, the test cases used for acceptance, and the fallback administrator setup. It should also state the deliverables, such as configuration records and an operations runbook, and the responsibilities that stay with your team, such as providing identity administrator access and approving changes. Confirm what is excluded, including Metabase licenses, identity provider licensing, and any SSO-based embedding work. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope. Ask how change requests are priced and approved.

What breaks when Metabase group mapping is wrong after SSO goes live?

The most common failures are users landing in the wrong Metabase groups, which changes what data and collections they can see, and users being locked out because their groups no longer match. Attribute mismatches can also cause queries to return unexpected results when filters depend on user attributes. Another risk is losing administrator access if the only admin account relied on SSO and the identity provider changes. Before go-live, test one account per role and per group, confirm deprovisioning behavior, and keep a documented fallback admin with a secure credential process. Check the Metabase people and groups documentation for how group sync behaves in your plan, since sync options differ between editions. Run the same tests after every identity provider change or Metabase upgrade.

How DeployOpen works on this

DeployOpen scopes Metabase SSO and identity integration in writing before any build starts, then configures and tests the sign-in path inside your own infrastructure. Each engagement ends with documented settings, verified group mappings and a support option for ongoing changes.

How we scope

Confirm which identity provider you use and which Metabase edition you run, since SAML, OIDC, JWT and SCIM need Pro or Enterprise.
Map your identity groups and user attributes to the Metabase groups and permissions each team needs.
Agree the written scope, deliverables and timeline with you before work starts, since engagements are fixed-scope.

How we build

Configure the chosen sign-in method in your Metabase instance, including redirect addresses, certificates or client settings.
Set up group mapping and attribute sync so access follows your identity provider rather than manual user edits.
Test sign-in, group membership, deprovisioning and permission outcomes with representative test accounts before cutover.

How we hand over

Deliver a written record of the identity settings, mapping rules, fallback accounts and the owners of each configuration item.
Walk your administrators through how to add groups, change mappings and review access, using your own environment.
Document the test cases used and their results so your team can repeat them after later Metabase upgrades.

How we support

Offer ongoing support as a retainer for changes to identity settings, new groups and sign-in issues after go-live.
Review identity configuration again when you plan a Metabase upgrade, since sign-in settings can change between versions.
Confirm with your identity provider vendor and your own environment any setting that DeployOpen does not control directly.

Metabase SSO and identity integration