OpenBao SSO and identity integration guide

OpenBao SSO and identity integration: why it is harder than enabling a login method

Connecting OpenBao to your identity provider means choosing which identity source each audience uses, then mapping the groups that source issues to OpenBao policies so that access follows the people and workloads you already manage. OpenBao documents several auth methods, including JWT/OIDC, LDAP, Kubernetes, AppRole, TLS certificates, Userpass, tokens and username and password, along with login MFA. Turning any one of them on takes little effort. The difficulty lies in deciding which method serves which audience and in keeping the identity-to-policy mapping correct over time. The first audience question is usually the simplest to answer on paper: human operators on workstations, administrators, CI pipelines and running services each have different needs. OpenBao's own guidance points developer machines toward Userpass and servers toward AppRole, but your organization will likely need JWT/OIDC or LDAP for people, Kubernetes auth for pods, and TLS certificates or AppRole for machines outside the cluster. Before enabling anything, list every audience, its identity source, its lifecycle owner and the paths it must reach. Leaving one audience on a shared credential because no method was chosen for it is how static secrets return. Group drift is the most common long-term failure. An OIDC or LDAP group claim maps to a policy in OpenBao, and nothing forces those two systems to change together. When a team is renamed, split or removed in the identity provider, the mapping can silently grant access that nobody intended or block access that people still need. Confirm who owns each group-to-policy mapping, how changes are reviewed, and how you will detect a mapping that points at a group no longer in use. Treat the mapping file as code with the same review discipline as the policies themselves. Workload identity raises a different risk because it outlives people. A Kubernetes service account, an AppRole role or a certificate issued to a workload can keep working long after the team that deployed it has moved on. Ask who owns each workload identity, how its token time-to-live and secret ID rotation are set, and what happens when the workload is retired. Plan a periodic review that lists active workload roles and removes the ones with no owner. MFA adds a final gap. Login MFA in OpenBao can be attached to particular auth methods or paths, which means some routes may require a second factor while others, including automation routes, do not. Map every path that carries sensitive secrets or administrative capability, confirm which of them enforce MFA, and test the result with a user from each group. Confirm the exact MFA behavior for your OpenBao version with the official auth documentation before you write the access design.

Which OpenBao components carry identity: auth methods, policies, groups and MFA

Identity in OpenBao is spread across several components that work together: auth methods that verify who or what is logging in, policies that decide what a login may do, and identity groups that tie external groups to those policies. Login MFA, namespaces and audit devices add the boundaries and records that regulated environments usually ask about.

Auth method mounts

Each auth method is enabled at a path and configured separately, so a JWT/OIDC mount at one path and an LDAP mount at another can coexist. Choose methods by who logs in: JWT/OIDC or LDAP for people, Kubernetes, AppRole or TLS certificates for workloads, and Userpass where the documentation recommends it for developer machines. Confirm the exact configuration keys against the auth methods documentation for the version you run, since they differ by method.

Policies that grant capabilities

Policies define which paths a token may read, write, list or delete. Every external identity ends up with the capabilities of the policies attached to it, so policy design determines the real blast radius of an SSO login. Review each policy against the least-privilege intent and confirm that no broad wildcard grants slipped in during onboarding.

Identity groups and aliases

Identity groups and aliases connect groups from your identity provider or directory to OpenBao policies. An alias links an external identity from a specific auth mount to an entity, and a group attaches policies to many entities at once. Check that each external group name maps to exactly one intended OpenBao group, because a mistyped or reused group name can grant access that nobody reviewed.

Login MFA

OpenBao supports multi-factor authentication at login, which is separate from the MFA your identity provider may already enforce. Decide whether MFA is enforced by the identity provider, by OpenBao, or by both, and document which auth methods and paths require it. Test each login path with MFA enabled, including the workload methods where MFA does not apply, so no path quietly skips the control.

Namespaces for tenant boundaries

Namespaces give OpenBao a way to separate tenants or business units inside one cluster, each with its own auth mounts, policies and secrets. Decide early whether an identity source belongs to the root namespace or to a child namespace, because moving auth configuration later is more work than setting it up correctly. Confirm the namespace behavior for your version in the namespaces documentation.

Audit devices that record logins

Audit devices record requests and responses, including login attempts and the identity behind each token. Enable at least one audit device before onboarding users so that every login from the first day is recorded, and confirm where the logs go and who can read them. Check how audit logs handle sensitive values, since a log that exposes secrets creates its own exposure.

Which auth method fits people, servers, Kubernetes and certificates

This table compares the OpenBao auth methods for each kind of caller and names the operational cost that comes with each choice. Read each row as a starting point: the right option depends on whether a person or machine is signing in, where your identity provider sits, and who will rotate the credentials. The main takeaway is that no single method covers every caller, so most deployments combine two or three.

Caller	Recommended method and when it fits	Operational cost to plan for
People on developer machines	Userpass, the method OpenBao documents for developer machines. Fits small teams or local test clusters where no central identity provider is connected yet.	Credentials are stored and managed inside OpenBao, so you own password policy, account creation, offboarding and MFA setup for each user.
People through a central identity provider	JWT/OIDC or LDAP, so staff sign in with the same accounts they use elsewhere. Fits most production teams with an existing directory or SSO service.	Sign-in depends on the identity provider being available. Group quality in the provider drives which policies each person receives, so group hygiene becomes an operational task.
Servers and automation	AppRole, the method OpenBao documents for servers. Fits services that run outside Kubernetes and need a role ID and a delivered secret ID to log in.	The secret ID must be delivered to each host securely and renewed on a schedule. Confirm how your configuration management or orchestrator will handle that delivery.
Kubernetes workloads	Kubernetes auth. Fits pods that already carry a service account token and should not hold a separate OpenBao secret.	Each cluster must be trusted by OpenBao, so the cluster's review access and CA settings need upkeep. Service accounts and their bindings must be tracked as workloads change.
Machines identified by certificates	TLS certificate auth. Fits hosts or services that already receive client certificates from an internal certificate authority.	Certificate issuance, renewal and revocation are the main cost. Confirm who issues the client certificates and how quickly revoked certificates are refused.
Where group-to-policy mapping lives	In the identity provider claims when your provider is the source of truth for roles and teams. Choose OpenBao identity groups when you need OpenBao-specific policy grouping or when provider claims are unreliable.	Claim mapping lives in the provider's configuration, while identity groups add objects to maintain inside OpenBao. Pick one primary location so policy changes do not require edits in two places.
Login MFA	Enforced at login for the person-facing methods where your OpenBao version supports it. Fits any privileged or production access path.	Confirm which methods support MFA in your target version and how enrollment and recovery will work for users who lose a second factor.

How OpenBao SSO maps identity provider groups to policies

The mapping model is the part of OpenBao SSO that decides who can reach which secrets, so it deserves the most design time before rollout. In OpenBao, an external group or a claim value from your identity provider is linked to an OpenBao identity group or alias, and that OpenBao group carries one or more policies. A user who authenticates through JWT/OIDC or LDAP receives the policies attached to every group their login maps to, so the chain has three links you must govern: the IdP group, the link, and the policy set. Each link needs an owner and a written record. The largest risk sits in the identity provider. If an IdP group is broad, such as one that contains all engineers or every employee in a directory organizational unit, then every member inherits whatever OpenBao policies that group unlocks. Review the membership of each group that will be mapped, and confirm that the group exists for a secrets purpose rather than for email, VPN or general access. Where a group has grown by accident, create a narrower group for OpenBao use instead of reusing the existing one. Ask your IdP administrators who can add members, because a person who can modify group membership can also modify OpenBao access. Use one naming convention shared by the IdP and OpenBao. A pattern such as a team name, an environment and an access level, for example a prefix that marks the purpose, keeps the two systems aligned and makes audit trails readable. Agree the convention before creating any group, and write down how a new team requests a mapping. Without a shared convention, teams end up with near-duplicate groups in each system, and nobody can tell which OpenBao policy a given IdP group actually grants. Users who belong to several groups need deliberate handling. Do not solve this by creating one broad administrative policy that covers everything a user might need. Instead, keep each policy narrow, scoped to a team's paths and capabilities, and let OpenBao combine the policies that apply to that user. Review combined access for people in several groups, since the union of narrow policies can still be larger than any one team needs. Test the effective permissions of a user who sits in the most groups before approving the design. Document which group grants which path, with the capabilities it allows and the owner who approves changes. This record is what auditors, security engineers and the next administrator will rely on, and it is the fastest way to answer an access question during an incident. Confirm the exact claim fields for each IdP against the OpenBao JWT/OIDC and LDAP auth method documentation, since group claims and their names differ between providers. Then test with a real test user in a non-production cluster and check that the expected policies are attached before any production group is mapped.

Build sequence for OpenBao SSO, from identity provider to first verified login

This sequence takes an OpenBao cluster from an unconfigured auth stack to a first login that maps a tested person to the expected identity group and policy set. Each step ends with a check the team can record, so the build and its verification are documented before go-live.

Inventory identity sources and groups
Start by listing where people and workloads are authenticated today: the identity provider or directory, the groups that already control access, and any service accounts that need OpenBao access. Record which group owns which secret path and who approves changes to group membership. Confirm group attributes and claim names with the identity provider administrator before writing any OpenBao configuration. The step closes when the team has a signed-off inventory that names every source and group, including groups that exist only in the directory and not yet in OpenBao.
Decide the auth method per audience
Match each audience to an auth method the OpenBao documentation supports for that use. Human operators usually sign in through JWT/OIDC or LDAP, depending on what the identity provider offers. Developer workstations can use Userpass where policy allows, while servers, pipelines and clusters typically use AppRole, Kubernetes or TLS certificates. Write the decision down with its reason, owner and expected token lifetime. The step closes when the design record names one method per audience and the security owner has accepted it. Confirm current method options and their limits in the docs for the release you run.
Create test users and a break-glass admin path
Before configuring SSO, create a small set of test accounts in the identity provider that mirror each target group, including one account that should be denied. Create a dedicated administrative path in OpenBao, such as a named admin policy bound to a small group, that works without the root token. Store the recovery material for that path under your existing key custody procedure. The step closes when an administrator can authenticate through the admin path and the root token is held under documented control and is not used for daily work. Confirm the exact root token and recovery procedures in the docs for your release.
Configure the human auth method and verify group mapping
Enable the chosen human method, set the issuer or directory connection, and define the role or group mapping that turns identity provider claims or directory groups into OpenBao identity groups. Sign in with each test account. Each test login should land in the expected identity group and carry only the expected policies. Check the token's attached policies and group membership after every login. The step closes when each test account maps to its intended group and the denied account receives no token. Confirm claim names, bound audiences and TLS settings against the docs for the release in use.
Enforce login MFA on target paths
Where the design requires a second factor, enable login MFA on the auth method and attach it to the paths that need it, such as production secret paths and the admin path. Enroll a test account, then confirm the second factor is demanded on each target path. Also confirm that paths outside the design still behave as documented. Record which MFA method is in use and who manages enrollment and recovery. The step closes when a login without the second factor fails on a protected path and succeeds with it. Confirm MFA configuration fields and enforcement scope in the docs for your release, since enforcement details are where setups most often differ.
Configure workload auth and secret ID handling
Configure the workload methods from the design, such as AppRole for servers, Kubernetes auth for cluster workloads, or TLS certificate auth for services that hold issued certificates. For AppRole, decide how role IDs reach each host, how secret IDs are generated, delivered, limited in use and rotated, and bind each role to only the policies its workload needs. For Kubernetes, bind roles to specific service accounts and namespaces. The step closes when a test workload authenticates with its role, receives only its bound policies, and a login attempt from an unexpected host or account is refused. Confirm secret ID options and binding fields in the docs.
Attach least-privilege policies and test path access
Write one policy per group, grant only the capabilities each path requires, and attach it to the matching identity group. Keep wildcard paths to a short, reviewed list. Then test each group by signing in and attempting reads and writes on its own paths and on paths owned by other groups. The step closes when each group reaches its own paths, is denied on the others, and the test results are saved alongside the policy version that produced them. Repeat this check after any policy change.
Enable an audit device and document the mapping
Enable an audit device before go-live and confirm it records login events for the test accounts and workload logins, including denied attempts. Check that the device output goes to storage the security team can read and retain under its own policy. Then write the final mapping document with one row per identity source, method, group, policy, MFA requirement and owner. The step closes when a test login appears in the audit log and the mapping document matches the live configuration on a line-by-line review. Confirm audit device options and log format in the docs for your release.

What drives the effort of an OpenBao identity integration

This table lists the factors that most change how much work an OpenBao identity integration takes and how to keep each one contained. Read each row as a lever: the first column names the driver, the middle column explains why it moves effort, and the last column gives the reduction step to take early. The main takeaway is that group design, a single mapping standard and a pilot with one team tend to matter more than the auth method itself.

Driver	Why it changes effort	How to keep it down
Identity sources and groups	Each identity provider, LDAP directory or group claim needs its own mapping to OpenBao policies, and groups that overlap multiply review work.	Use fewer, well-named groups that map to a documented role, and remove groups nobody owns before mapping them.
Workload auth types and owners	AppRole, Kubernetes, TLS certificate and JWT workloads each need their own role configuration, and each owning team must agree on the identity it presents.	Standardize on one or two workload auth methods per platform, and record a named owner for every role in the same register.
MFA scope and policy exceptions	Deciding which logins require a second factor, and handling service accounts or break-glass access separately, creates branching decisions and test cases.	Define MFA scope once as a short policy, keep exceptions few and time-limited, and document each exception with an approver.
Namespaces or tenants	Each namespace can carry its own auth mounts, mappings and policies, so every new tenant repeats configuration and testing.	Create a reusable namespace template with standard mounts and mapping files, and add tenants only when isolation is actually required.
Environments (dev, staging, production)	Each environment needs matching mappings and separate verification, and drift between them is a common source of failed promotions.	Keep mappings in version-controlled configuration applied to every environment, and promote the same files rather than editing each cluster by hand.
Access reviews and evidence requirements	Reviewers need to see who holds which policy and why, and assessors ask for proof that reviews happened on schedule.	Export group-to-policy mappings in a consistent format and schedule reviews on the same cadence as your existing identity reviews.
Joiner-mover-leaver and ticketing integration	Connecting group membership to your ticketing or HR-driven joiner-mover-leaver process adds interfaces, approvals and failure cases to test.	Tie access to existing group membership in the identity provider, so OpenBao follows that source instead of a second list, and confirm the process with your IAM owner first.
Pilot scope before expansion	Expanding to every team at once multiplies unresolved mapping questions and makes it hard to tell which change caused a problem.	Pilot with one team and one environment, record the mapping decisions made, then reuse that standard for each later team.

How identity integration changes across single node, HA, Kubernetes and air-gapped deployments

A single OpenBao node has the fewest moving parts, which makes identity integration easier to build and test. The trade-off is that the login path has no redundancy. If the identity provider, the network path to it or the node's auth configuration fails, people and workloads that depend on that path lose access to secrets. Plan for this before go-live rather than during an incident.

Break-glass access: Document a procedure that does not depend on the root token and does not depend on the primary identity provider. Confirm the recovery method and who is authorized to use it in the auth and policy documentation.
Root token handling: Confirm how root tokens are generated, stored and revoked, and keep them out of routine operations.
Single login path failure: Test what happens to human and workload logins when the identity provider is unreachable, including cached tokens and lease expiry.
Config and backup: Keep auth method configuration in version control so the node can be rebuilt with the same login behavior.
Upgrade window: Plan identity checks as part of any restart or upgrade, since a single node has no peer to take over.

Before you commit to a single node, confirm the documented break-glass path with your security team and run one login test per auth method while the identity provider is deliberately taken offline in a non-production environment.

How to keep identity access to OpenBao least-privilege and auditable

Identity integration makes OpenBao easy to reach, so the access paths need the same scrutiny as the secrets behind them. The cards below cover the controls that keep human, workload and administrative access narrow, time-limited and visible in logs.

Restrict and retire the root token

The root token bypasses normal policy evaluation, so it should not be used for daily logins or automation. Confirm that SSO users and workloads receive scoped tokens from their auth methods, and that any root token used during setup is revoked once administrative roles exist. Keep the procedure for generating a new root token documented, owned and tested, since you will need it for recovery. General root token handling is covered in the security hardening topic.

Shorten and control AppRole secret IDs

AppRole secret IDs act as the password for servers and services, so their lifetime and delivery matter more than their existence. Set short time-to-live values and limited use counts where your automation allows it, and confirm that the secret ID is delivered through a channel your configuration management or orchestrator already protects. Ask who can generate secret IDs for each role, and whether that right is separate from the right to read the role ID.

Bind Kubernetes and certificate roles tightly

Kubernetes and TLS certificate auth methods are only as narrow as their role bindings. For Kubernetes, bind each role to specific namespaces and service accounts rather than broad namespace selectors. For certificate roles, match on attributes such as common name, DNS names or organizational unit, and confirm that the trusted CA is limited to the issuers you actually operate. Test each binding with an identity that should be refused to confirm the restriction holds.

Enforce MFA on privileged groups

Login MFA is available in OpenBao, but it applies only where it is configured against the auth method and identity group that matters. Identify which groups can read high-value secrets, change policies or manage auth methods, and require MFA for those logins first. Confirm with your identity provider that group membership changes are reflected in OpenBao, so that a user removed from an administrator group loses that access on the next login.

Validate TLS to the identity provider

OpenBao calls the identity provider for JWT/OIDC discovery, LDAP binds and similar exchanges, so a weak connection there can undermine the whole login chain. Use TLS for every connection, supply the correct CA chain, and keep certificate verification enabled rather than skipping it during testing. Record the certificate expiry dates for both sides and agree on who renews them. Transport and listener settings in general are described in the security hardening topic.

Scope and review group policies

Map each identity group to the narrowest policy that supports its work, and keep those mappings in version control so changes are reviewed. Avoid granting wildcard paths for convenience, and treat policies that combine read, update and delete on broad mounts as exceptions that need a named owner. Schedule periodic reviews that compare group membership with the policies attached to it, and remove mappings for teams or systems that no longer exist.

Retain audit logs of logins and changes

Audit devices record authentication attempts and policy or mount changes, and those records are what an auditor or incident responder will ask for first. Enable at least one audit device, confirm where its output goes, and check that failures and policy writes appear in it. Decide how long logs are retained, who can read them, and how you will detect a gap if the device fails. Ask your auditor which events they expect to see before you finalize the configuration.

How to test that OpenBao SSO works and fails safely

The most useful test plan for OpenBao SSO proves two things: that each person and workload gets exactly the access its group or identity should carry, and that the cluster refuses access in the cases where it should. Both halves matter. A login that succeeds is only half a result if the policies attached to it are wider than intended, and a denial that happens for the wrong reason can hide a broken mapping. Write the expected result for every test before you run it, so a pass means the outcome matched a written expectation rather than something that merely looked reasonable.

Start with positive tests. Pick at least one test user from each group that your JWT/OIDC or LDAP mapping covers, and have each one log in through the method that group is meant to use. Confirm that the token carries the policies you expect and nothing else. Check the group-to-policy mapping in both directions: a user in the platform group should not receive the database administrator policy because they share a team name with someone who does. Record the token's identity alias, entity and attached policies so the same check can be repeated after an IdP change or an OpenBao upgrade.

Next, run the negative tests, which are where most SSO mistakes surface. Confirm that a user outside every mapped group is denied, that an account disabled or removed in the identity provider cannot obtain a new token, and that an existing token from a removed account stops working once its lease ends. Test privileged paths with a user who has not completed MFA and confirm the login is refused on those paths. Also check that the MFA requirement cannot be skipped by calling the API directly rather than through the normal CLI or UI flow. Ask your identity team to confirm which MFA method your provider enforces, because OpenBao will only ever see what the provider asserts.

Workload tests follow the same logic for AppRole, Kubernetes and certificate identities. For each one, confirm that the identity reads its own paths and is refused on a neighbouring path, including a path that belongs to a different application in the same namespace. Failure tests come last and need planning, because they stop real dependencies. Stop the identity provider or the LDAP server in a test environment and record exactly what happens to existing tokens, new logins and running workloads. Then confirm that the documented break-glass path works without the failed provider, and that the break-glass credentials are stored and rotated as your procedure states. In a clustered deployment, force a leader change and confirm that a standby node accepts logins and applies the same policies.

Every attempt, successful or not, should appear in the audit log with the identity, the auth method, the decision and the policies applied. Test this directly by reading the audit device output for each scenario above and checking that no attempt is missing. Then turn these checks into repeatable scripts that run against a non-production cluster after every configuration change, IdP change and upgrade. The scripts should fail loudly when an expected denial becomes an allow. Ask your implementation partner, or confirm internally, who owns the test accounts, how they are provisioned and removed, and where the results are kept as evidence.

What to run, review and document after SSO goes live

Once OpenBao trusts your identity provider, the access model needs regular upkeep: people leave, groups change, credentials age and releases move. The cards below cover the recurring checks and records that keep that model accurate, and they connect to the upgrades and support work that keeps the auth configuration working across release lines.

Review group membership and leavers

Schedule reviews of which identity provider groups map to which OpenBao policies, and confirm that removing a person in the IdP also ends their OpenBao access. Check that tokens issued through OIDC, LDAP or JWT login expire on the lifetimes you set, so a departed user cannot keep working from an existing token. Ask your IdP team which deprovisioning path applies to contractors and service accounts.

Rotate workload credentials on schedule

AppRole secret IDs, Kubernetes service account bindings and certificate-based logins each have their own renewal behavior. Rotate or re-issue them on the schedule your design sets, and record which workloads depend on each credential so a rotation does not break a running service. Confirm the rotation steps with your application owners before the first scheduled cycle.

Watch audit output for failed logins

Send audit device output to your log platform and alert on repeated failed logins, logins from unexpected auth methods and changes to policies or auth method configuration. Failed-login patterns often show a misconfigured client or a credential leak before they show an attack. Confirm which fields your SIEM needs from the audit log, and test that the alerts fire on a deliberate failed login in a non-production cluster.

Re-run negative tests after changes

After each OpenBao upgrade, IdP certificate or client rotation, and group rename, repeat the negative tests from the design: a user outside the mapped groups should be denied, an expired token should be refused, and an unmapped JWT claim should not grant a policy. Keep the test cases in source control so they run the same way each time. Record the results with the change ticket.

Keep group-to-policy mapping in version control

Store the mapping from identity provider groups to OpenBao roles and policies as code, with reviews required for every change. Version control gives you a history of who granted which access and when, and it lets you roll back a bad mapping quickly. Confirm who may approve changes to privileged policies and whether your change process requires a second reviewer.

Record and review break-glass use

Define the emergency access path, such as a sealed root credential or a dedicated break-glass group, and log every use of it. Each use should have a ticket or incident reference, a named approver and a review after the event that confirms the access was needed and was removed. Test the break-glass procedure on a schedule so the people who need it know where the credentials are held.

Document the owner of each identity source

For every identity source OpenBao trusts, such as an OIDC provider, an LDAP directory or a Kubernetes cluster, record the team that owns it, the contact for outages and the process for changing its settings. When a directory certificate expires or a group is restructured, the owner should be known before OpenBao logins start failing. Keep this register with the rest of your OpenBao runbooks.

Questions buyers and engineers ask before integrating OpenBao SSO

What drives the cost of an OpenBao SSO integration?

The number of integration points and how much design work they need drive most of the cost. The work has four parts: discovery and design (identity sources, group model, policy mapping), configuration of auth methods and policies in OpenBao, testing with dedicated test accounts, and the evidence and handover your team keeps. Costs rise with each additional identity source, each group that must map to its own policy, each workload path (Kubernetes, AppRole, certificates) and each MFA rule. Most of the effort is one-time, but changes to group membership, policies and auth configuration recur, as does maintenance after OpenBao upgrades. Ask any provider for a written scope that lists every identity source, auth method, group-to-policy mapping, MFA requirement, environment, test plan, deliverable and exclusion. DeployOpen works on fixed scopes agreed in writing before work starts, and the quote follows from that scope.

How long does OpenBao SSO integration take to set up?

The timeline depends on the scope, not on OpenBao alone, so ask for an estimate tied to a written scope rather than a generic figure. Four factors set the schedule: the number of identity sources (for example, one OIDC provider or several directories), the number of groups that need distinct policies, the workload paths in scope (Kubernetes, AppRole, certificates) and the MFA requirements for each login path. Delays usually come from slow access approvals, unclear group ownership and late decisions about which users may use which methods. Testing across roles and environments adds time, and so does a change window for production. Before agreeing a date, confirm who approves changes, how many environments must pass testing, and which items are dependencies on your side. DeployOpen agrees timelines in writing as part of the fixed scope.

What do we need to provide before an OpenBao SSO project starts?

The project needs access, information and decisions from your side before design begins. Expect to provide:

Identity provider access: an admin or delegated role that can register OpenBao as a client application and manage claims or group mappings.
Group inventory: a list of groups, their members, their owners and the access each should receive.
Test accounts: one per role, kept separate from production users.
Network paths: routes from OpenBao nodes to the identity provider, LDAP servers or Kubernetes API endpoints, including DNS and certificate trust.
Decision owners: named people who approve policy mappings, MFA rules and the production cutover.

Missing items are the most common cause of schedule slips, so confirm each one in the scope document before work starts.

Can our internal team integrate OpenBao with our identity provider themselves?

Yes, an internal team can do this if it has working experience with both OpenBao and the identity provider, plus a written test plan. The team must understand the auth method configuration, token and lease behavior, policy design and the identity provider's claim or group model. Without that, errors tend to show up as access that is too broad or too narrow, which is harder to find after go-live. An outside partner adds value in three places: scoping the work before build starts, building the integration in your environment, and producing the evidence your auditors or internal reviewers ask for. DeployOpen plans, implements and documents self-hosted OpenBao inside your own infrastructure, and it does not issue audit reports or certifications, which independent assessors provide.

Should we allow Userpass or a shared password for production administrators?

No. Shared passwords remove individual accountability, and they make it hard to tell who changed a secret or policy. OpenBao's documentation recommends Userpass for developer machines and AppRole for servers, so production people should sign in through your identity provider using OIDC or LDAP, with each person's own account. Keep Userpass limited to the use the documentation describes, and remove any shared accounts before go-live. Use separate, individually held break-glass credentials for emergencies, store them under dual control, and log their use. Review the active auth methods regularly, because a forgotten method can become a path around your identity controls. Confirm the current guidance for each auth method in the OpenBao docs before you publish your access standard.

What happens to OpenBao logins if our identity provider goes down?

New interactive logins through the identity provider will fail while it is down, so the design must include a documented fallback before an outage happens. Start by checking how long existing tokens stay valid under your token lifetime settings, because a short lifetime limits exposure but forces more frequent logins during an outage. Keep break-glass accounts that are separate from the identity provider, held under dual control, used only for emergencies, and audited every time. Store unseal or recovery material separately from the people who would use the emergency path. Run an outage drill that proves the fallback works and that the team knows who may invoke it. Also confirm how your high availability design handles provider failures, since OpenBao's own availability does not depend on the identity provider.

Can OpenBao enforce MFA for every authentication method?

Do not assume it can. OpenBao documents login MFA as a feature, but whether each auth method supports it, and how it is configured, must be confirmed per method in the OpenBao auth methods documentation for the version you run. Check each method you plan to use, including JWT/OIDC, LDAP, Kubernetes, AppRole, TLS certificates, tokens and Userpass. Where MFA is enforced by the identity provider rather than by OpenBao, record that dependency in your design and test it. For workload methods such as AppRole or Kubernetes, MFA usually does not apply in the same way, so document the compensating controls, such as tightly scoped roles, short token lifetimes and network restrictions. Put the result of this check into your written scope so reviewers can see which path enforces MFA and which relies on another control.

How DeployOpen scopes, builds and hands over OpenBao SSO integration

DeployOpen connects OpenBao to your identity provider through a written scope, built and tested in your own infrastructure, then handed over with documentation your team can run. Engagements are fixed-scope, and ongoing support is available as a retainer once the integration is live.

How we scope

We confirm which identity provider you use and whether it reaches OpenBao over JWT/OIDC, LDAP or both.
We list the workloads that need access, such as Kubernetes service accounts, AppRole-based servers and certificate-based clients.
We map existing groups to OpenBao policies and agree in writing which MFA requirements apply to each login path.

How we build

We configure each auth method in a non-production OpenBao environment, then test group-to-policy mappings with named test identities.
We verify login MFA behavior, token lifetimes and lease handling against the policies agreed in the scope.
We check that auth configuration is reproducible, so changes can be reviewed and applied the same way across environments.

How we hand over

You receive documentation of each auth method, its configuration, the policy mappings and the test cases used to verify them.
We walk your identity and platform teams through the login flows, troubleshooting steps and how to add a new group or workload.
Handover covers which settings your team owns after go-live and which changes should go through a review process.

How we support

Ongoing support covers SSO and identity configuration as your identity provider, Kubernetes clusters and OpenBao versions change.
A retainer can include reviewing auth method changes before they reach production and retesting group mappings after upgrades.
Ask any provider to confirm response times, upgrade coverage and what is included before you sign a support agreement.