How do we put OpenStack SSO behind our existing identity provider?
Keystone can federate with an identity provider over SAML 2.0 or OpenID Connect, so users sign in with the corporate directory instead of local Keystone passwords. The harder part is not the protocol handshake. It is mapping each federated user to the right groups, roles and projects, and keeping that mapping correct as people join, move and leave. Keystone applies mapping rules to match attributes from a trusted identity provider to OpenStack groups, roles and projects, so the mapping is where access decisions actually live.
Teams usually need this once a cloud has several groups sharing projects, when audit requirements ask who accessed which tenant and when, or when joiner and leaver control has to be enforced from the directory rather than by hand in Keystone. A local password store can work for a pilot, but it leaves offboarding as a separate manual task that is easy to miss. Federation moves that control to the system that already governs staff access, which is the main reason most regulated operators ask for it early.
Several things make this harder than it looks. Trust configuration is the first: the identity provider's metadata or client registration, signing certificates, redirect URIs and the Keystone federation settings must all agree, and a certificate rotation can break logins without changing any OpenStack setting. Claim quality is the second. If the identity provider sends a group or department attribute with inconsistent names, empty values or multiple formats, the mapping matches the wrong users or none at all. Confirm with your directory team exactly which attributes are available and how they are populated before writing rules.
Mapping rules are the most common silent failure. A rule that does not match simply grants no access, so users see an empty project list rather than an error, and a rule that matches too broadly can grant an administrator role to a large group. Write a test matrix of expected users, groups and resulting roles, and check it against each change. Keep the rules and the identity provider configuration in version control, with a named owner for each change.
Plan for upgrades from the start. Federation settings, mapping rules and the Horizon login path are touched by service upgrades, so the setup must be captured in your deployment configuration and retested after every upgrade within the maintained release window. Ask any implementation partner to show how the federation config is deployed, how rollback works if a login path breaks, and which test accounts are kept for verification after cutover.
Which components take part in OpenStack identity integration?
An OpenStack SSO design touches several parts that must agree before any user can log in. Keystone issues the tokens, your identity provider authenticates people, and mapping rules decide what each person may access once the token exists.
Keystone as the token issuer
Keystone is the OpenStack identity service that issues the tokens every other service accepts. Federated users still receive Keystone tokens, so Keystone remains the point where authorization decisions are made. Check which Keystone release your target OpenStack version ships, and confirm that federation is enabled in the deployment tool you plan to use before designing around it.
External identity provider
The identity provider authenticates users and asserts their attributes to Keystone, and it is usually the system of record your staff already use. Decide which provider holds the authoritative user list, who administers it, and how quickly a removed employee loses access to the cloud. Confirm that the provider can issue the assertions or claims Keystone needs under your chosen protocol.
SAML 2.0 or OpenID Connect protocol
The federation protocol defines how the identity provider passes authentication results to Keystone. Keystone federation documentation covers both SAML 2.0 and OpenID Connect, so the choice usually follows what your identity provider already supports well. Record the protocol, signing certificates or client registration details, and the metadata exchange steps, since these are the first items that break during setup.
Mapping rules for groups, roles and projects
Mapping rules translate incoming attributes from the trusted identity provider into OpenStack groups, roles and projects. This is where access is actually granted, so an error here can give users more rights than intended. Agree the attribute-to-role matrix with the owners of each project before go-live, and plan a review step for every change to the rules.
Optional LDAP backend
Keystone can read users and groups from an LDAP directory instead of storing them in its own database. This suits organizations whose directory already holds the authoritative identities, but it adds a dependency on directory availability and on directory query performance. Confirm which attributes Keystone must read, whether the bind account is read-only, and how the LDAP setup interacts with federated logins.
Horizon and API clients
Horizon, the OpenStack dashboard, and the command-line and API clients consume the tokens Keystone issues. Each consumer must point at the same Keystone endpoint and trust the same certificate chain, or logins will fail in ways that look like identity errors. Test a federated login through the dashboard, the CLI and a direct API call, because each path exercises a different part of the configuration.
Which federation protocol and trust model should we choose?
This table compares the main federation and trust decisions for Keystone, showing when each option fits and what it costs to operate. Read each row against your identity provider's protocol support and claim formats, and confirm both with your identity provider vendor before you choose. The main takeaway is that group ownership and region layout drive most of the ongoing upkeep, so settle those decisions first.
| Decision and option | When it fits | Operational cost |
|---|---|---|
| SAML 2.0 for the identity provider | Your corporate IdP already issues SAML assertions and your team runs that federation today. | Signing certificates and IdP metadata must be renewed and reloaded into Keystone at each rotation. |
| OpenID Connect for the identity provider | The IdP offers OIDC clients and you want token claims in a current format. | Client registration, key or secret rotation, and claim names must match mapping rules. Confirm with the vendor. |
| Direct federation to the corporate IdP | One IdP of record and a small number of OpenStack endpoints that trust it directly. | Each new Keystone or service provider needs its own trust entry, metadata or client configuration. |
| Brokered through an intermediate identity service | Several upstream IdPs, partner logins or protocol translation are required. | An extra service to run, patch and monitor, and a second place where claims can be altered or dropped. |
| LDAP as read-only user and group source | The directory is the authority for users and Keystone only needs to look them up. | A directory service account, certificate trust and query tuning. Group changes flow in without Keystone writes. |
| IdP owns group membership | Groups are already maintained in the IdP and sent as claims at each login. | Mapping rules depend on claim names and group identifiers. A group rename can cut off access until mappings are updated. |
| One Keystone per region | Regions must run independently, with local failure domains and local administration. | Each region holds its own user and project data. Tokens from one region are not accepted elsewhere without separate trust setup. |
| Keystone-to-Keystone federation | A central Keystone authenticates users for other regions or clouds that trust it. | The central Keystone becomes a dependency for every region. Token validity and outage behavior must be tested. |
| Map by group membership versus named user | Access follows a few groups that match job functions, with named mappings only for exceptions. | Group mappings need fewer changes, but claims must stay accurate. Named-user mappings need a change for every joiner, mover and leaver. |
How do we build OpenStack SSO step by step?
This sequence connects OpenStack to your identity provider so people sign in once and receive Keystone access that matches your role design. Each step produces a named artifact and closes with a check, so faults surface before the next layer depends on them.
Confirm the target release and its maintenance status
The architect checks the OpenStack releases schedule to confirm which release you will deploy and whether it is in the maintained phase. The supplied release data lists 2026.1 Gazpacho as a SLURP release, 2025.1 Epoxy and 2025.2 Flamingo as maintained, and 2026.2 Hibiscus as released on 2026-09-30. Output: a short release record naming the release, its support status and its upgrade path. Check: the release shows as maintained on the official schedule on the day the record is signed, and your team is working from that release's deployment guide.
Decide the protocol and trust model
Choose SAML 2.0 or OpenID Connect based on what your identity provider supports and what your security team can operate. Document which identity provider is trusted, which assertion or token claims carry group membership, and whether Keystone-to-Keystone federation is needed for a second cloud. Output: a trust model record covering protocol, issuer, audience, signing certificate ownership and the owner of certificate rotation. Check: the security owner and the identity owner both sign the record, and every attribute the mapping will need appears in a test assertion or token from the identity provider.
Register the service provider or client
Create the OpenStack relying party in the identity provider, using the Keystone federation endpoint for your deployment as the callback address. For SAML, exchange the service provider metadata file over TLS and confirm the entity ID matches the Keystone configuration. For OpenID Connect, register the client, scopes and redirect URIs, and pass the client secret through a channel your secrets process controls. Output: a metadata file or client record stored in version control, with no secrets in it. Check: the identity provider accepts the registration and a test login reaches the Keystone callback.
Configure Keystone federation and trusted providers
Enable federation in Keystone, register the identity provider entry with its issuer and signing material, and define the protocol entry that links that provider to the federated login path. Keep these settings in the same repository as the deployment inventory so every change is reviewed. Output: identity provider and protocol definitions in the Keystone configuration, committed to version control. Check: the identity provider and protocol appear in the Keystone API listing, and an unauthenticated request to the federated login URL redirects to your identity provider without returning an error.
Write mapping rules for one test group
Write a mapping rules file that matches a single test group from the identity provider to one Keystone group, then map that group to a test project with a reader role. Keep the rule set small so every match is easy to trace back to its source. Output: a rules file covering the test group, reviewed by the identity owner. Check: a test user in the group receives a token scoped to the test project with the expected role, and a test user outside the group is denied.
Map groups to projects and roles
Apply the agreed role design to all production groups, adding one mapping at a time and using the role matrix as the source of truth. Exclude broad matches, such as any authenticated user receiving a role, from the final rule set. Output: the complete role matrix and the full mapping rules file. Check: a test user in each group receives exactly the projects and roles listed in the matrix, and a review of the rules file finds no group that matches more access than the matrix allows.
Enable federated login in Horizon and the API
Turn on the federated login path in the Horizon configuration and confirm that the API accepts federated tokens for the same users. Keep local break-glass accounts for administrators and document how and when they are used. Output: updated Horizon and API configuration committed to version control, plus a written break-glass procedure. Check: a mapped user signs in through the browser and through the command line or SDK with identical access, and the break-glass path has been tested in staging.
Run verification tests before handover
Test each path end to end: browser login, API token issuance, token expiry, removal from a group, denied access for unmapped users, and the identity provider being unavailable. Record each result against the role matrix. Output: a verification report showing pass or fail for every test, with a named owner for each fix. Check: every test passes or has a documented, accepted exception, and the rollback path has been exercised in a non-production environment before any production cutover.
How do mapping rules turn identity provider claims into project roles?
Mapping rules are the part of an OpenStack SSO build that decides who gets into which project and with what role, so they carry more risk than most of the configuration. In Keystone federation, an identity provider sends a SAML 2.0 assertion or an OpenID Connect ID token carrying attributes, often called claims. Keystone compares those attributes against the conditions in a mapping rule set. Each rule that matches assigns the federated user to one or more groups, and the groups are then tied to projects and roles through the role assignments you have already defined in Keystone. A rule set is therefore a translation layer: it turns the identity provider's vocabulary (department names, group memberships, email domains) into OpenStack's vocabulary of groups, projects and roles.
Rules are the highest-risk element because their failures are quiet. A match condition that is broader than intended can grant a user access to a production project they should never see, and nothing in the login flow will show the error. A claim that is missing or renamed at the identity provider does not usually fail loudly. The user authenticates successfully, matches no rule, and lands with no project access, which looks to them like a broken cloud rather than a policy problem. Rule order also matters. Keystone evaluates the rule set in the order it is written and applies the matches it finds, so a permissive early rule can make a later, more restrictive rule irrelevant. Confirm how your release handles multiple matches and ordering, and check the syntax of conditions, including any regular expression or list support, against the Keystone documentation for the release you run, because details differ between releases.
Treat the rule set as code. Store the mapping definitions in version control alongside the rest of the deployment configuration, so every change has an author, a review and a rollback point. Before enabling a change, test it with sample assertions or ID tokens that represent the users you expect to match and, just as important, the users you expect not to match. Capture real claim sets from a non-production identity provider tenant where possible, and record the expected group, project and role for each sample. Repeat the test whenever the identity provider changes a claim name, an attribute format or a group definition, because those changes are the most common cause of silent access loss.
Define a default-deny outcome for unmatched users and verify it. The intended behavior for a federated user who matches no rule should be no project access and no roles, with a clear message that points to the administrator. Write a test case for this outcome and include it in your validation set, since it is the case most likely to be missed. Keep a short list of who can edit mapping rules and who can approve those changes, because a rule change is effectively a change to who can use the cloud. Ask your integration partner or internal team to confirm, in writing, how the default-deny behavior works in the release you deploy and how it is reflected in logs, so that an unexpected login can be traced to the rule that allowed it.
Plan for the operational side of rules as well. Identity providers change over time, teams reorganize and new projects are created, so rule sets accumulate exceptions unless someone owns their lifecycle. Schedule periodic reviews that compare the active rules with current project ownership and group membership, and retire rules that no longer match any real user. Record the purpose of each rule in the same file that defines it. This keeps the mapping model understandable to the next engineer who has to troubleshoot an access request, and it gives auditors a clear trail from a claim, to a rule, to a project role.
How do we secure OpenStack SSO without locking out operators?
Federating Keystone with an identity provider or LDAP moves trust decisions out of OpenStack and into certificates, secrets, mapping rules and bind accounts. The controls below cover those identity-specific trust points, so operators keep access during an IdP outage and an attacker cannot gain admin through a misconfigured mapping. Broader Keystone policy and API hardening is covered separately in the OpenStack security hardening work.
TLS on metadata and token endpoints
Keystone federation depends on the identity provider's SAML metadata or OpenID Connect discovery document and on the token endpoints that exchange credentials. Serve these over TLS with certificates that chain to a CA your operators trust, and confirm that Keystone and the IdP verify each other's certificates rather than disabling verification to get a login working. Check certificate expiry dates and renewal ownership before go-live.
Pinning and rotating the IdP signing certificate
Keystone must validate SAML assertions and OpenID Connect tokens against the IdP's signing key. Record the certificate or key identifier you trust, limit where it is stored, and agree a rotation procedure with the IdP team that includes overlap windows so both old and new keys are accepted during the change. Ask who is notified before the IdP rotates and how a bad rotation is rolled back.
Validating assertion audience and expiry
A signed token is not enough on its own. Configure Keystone to check that the assertion or token is issued to this OpenStack federation client (audience), that its validity window has not passed, and that the issuer matches the trusted IdP. Test with a token issued for a different relying party and with an expired token, and confirm both are refused. Clock skew between Keystone hosts and the IdP can cause false rejections, so verify time synchronization first.
OpenID Connect client secrets outside config files
The OpenID Connect client secret authorizes Keystone to the IdP. Keep it out of keystone.conf, Ansible inventories and version control. Load it from a secrets manager or an encrypted store with restricted read access to the Keystone service account, and confirm that deployment tooling and logs do not echo it. Plan a rotation path that updates the IdP and all Keystone nodes in one controlled change.
Least-privilege mapping that never grants admin by default
Keystone mapping rules translate IdP claims or groups into OpenStack groups, roles and projects. Start with member or reader roles, grant admin only through an explicit rule tied to a named IdP group, and scope each rule to specific domains or projects. Review rules as code, and test them with sample assertions from each group to confirm that a user outside the admin group cannot match an admin rule through a broad or wildcard condition.
Break-glass local administrator account
If the IdP or federation path fails, operators still need a way into Keystone. Create a local administrator account with a long, unique credential held in a sealed store, and enable it only for documented emergencies. Give it separate monitoring, alert on every use, and rotate its credential after each use. Test the break-glass path before production go-live, since an untested emergency login is often the first thing that fails.
LDAP bind account scope
When Keystone reads users and groups from LDAP, its bind account needs only read access to the directory subtrees that hold users and groups used by OpenStack. Give it no write rights and no access to password attributes, and use a dedicated account rather than an administrator's. Ask the directory team to confirm the account is excluded from interactive login and that its password is rotated under the same policy as other service accounts.
What drives the effort and cost of OpenStack identity integration?
This table lists the factors that change how much work OpenStack identity integration takes, who carries each part of that work, and which costs are one-time versus recurring. Use it to shape the written scope and to check that a quote covers the drivers that apply to your environment.
| Driver | Who pays and what is one-time or recurring | How to keep it down | What to ask for in a written quote |
|---|---|---|---|
| Number of identity providers and protocols | Internal identity team and the IdP vendor's administrators. One-time: trust setup for each SAML 2.0 or OpenID Connect provider. Recurring: metadata and client changes when providers change. | Standardize on one corporate IdP for Horizon and the CLI where possible. Document each protocol's trust and claim contract before build. | Each IdP and protocol listed separately, with trust setup, testing and handover for each one. |
| Quality and consistency of group and attribute data | Directory team. One-time: cleanup of group names, attributes and mapping inputs. Recurring: fixes when HR or directory data drifts. | Agree attribute names and group naming conventions with the directory owner before writing mapping rules. Remove stale groups. | Whether directory cleanup is in scope, who performs it, and how the partner validates the claims that reach Keystone. |
| Number of groups and projects that need mapping | Partner or internal engineers for rule design. One-time: mapping rules and role tests. Recurring: rule updates for every new team, project or role. | Map to a small set of group-to-role patterns instead of one rule per user group. Keep project creation under an owned process. | Count of mapping rules, projects and roles in scope, and how changes after handover are priced. |
| Number of regions or Keystone instances | Platform team and partner. One-time: federation setup per region and per Keystone instance. Recurring: certificate and metadata changes in each place. | Use one authoritative identity source where the design allows. Automate configuration with the deployment tooling. | Per-region and per-Keystone effort, and whether Keystone-to-Keystone federation is included or a separate item. |
| LDAP directory structure and read-only access | Directory team sets access. One-time: service account, search base and attribute mapping. Recurring: changes to directory schema or access reviews. | Confirm with the directory owner that Keystone gets a read-only bind account with narrow search scope. Test nested group behavior early. | Whether the quote assumes a read-only directory, who approves the bind account, and what happens if schema changes. |
| Compliance evidence the team must produce | Internal compliance and security staff, with the partner preparing exports and records. One-time: control mapping and evidence set. Recurring: periodic access reviews and log retention checks. | Agree the evidence list before build so logs, configuration exports and approval records are captured as the work happens. DeployOpen prepares evidence; auditors and certification bodies assess it. | Named evidence artifacts, formats, and who reviews them. Confirm that the work does not include audit opinions. |
| Custom login branding in Horizon | Internal design or brand team, with the partner applying changes. One-time: template and theme work. Recurring: retesting after each OpenStack upgrade. | Keep branding to supported theme or template overrides so upgrades stay routine. Avoid edits to core dashboard files. | Scope of branding changes, the upgrade regression tests that cover them, and who owns the custom files afterward. |
| Certificate rotation and federation metadata upkeep | Platform operations team. Recurring: certificate renewal, metadata refresh and trust checks at each IdP. | Track certificate expiry dates in the monitoring system. Automate metadata refresh where the IdP supports it. | Whether rotation is covered by a retainer, the notice needed from the IdP, and the test steps after each rotation. |
How do we test that OpenStack SSO works and fails safely?
A federated login is only trustworthy once you have shown that it grants the right access to the right people and refuses everyone else. Your test plan for Keystone federation should cover both sides, and the failure side deserves at least as much time as the success side. Write the cases down before the first integration run, assign each one an owner, and record the expected result in the same terms the auditor and the identity team will use. On the success side, log in once for each group you have mapped in the Keystone mapping rules. For every group, confirm that the user lands in the expected domain, project and role, and that the token issued by Keystone carries exactly that project scope and those roles. Check the scope from the token itself, not only from the Horizon dashboard, because the dashboard can hide a role the user does not actually hold. Run the same check for a user who belongs to more than one group, since rule ordering and overlapping mappings are a common source of unexpected roles. On the denial side, test a user who exists in the identity provider but belongs to no mapped group. Keystone should refuse to issue a scoped token for that user, and the refusal should be visible in the Keystone logs. Next, remove a test user from the directory or from the relevant group and confirm that access ends at the next token issuance, not at some later cache expiry you never checked. Also present a bad or expired assertion, such as a tampered signature, a wrong audience, or an assertion past its validity window, and confirm that it is rejected. Your identity team should confirm the exact token lifetimes and cache behavior in their own environment. The outage test matters most for safe failure. Stop or block the identity provider in a test environment and confirm that users are refused cleanly, while the local break-glass administrator account still authenticates to the OpenStack APIs and Horizon. Store the break-glass credentials under the controls your organization already uses for privileged accounts, and test that access on a schedule rather than assuming it works. Verify that the break-glass path is logged and alerted on, because its use should always be a reviewable event. Finally, treat this suite as a regression test, not a one-time acceptance step. Re-run it after any change to the identity provider, after certificate rotation for the SAML signing or metadata keys, and after every OpenStack upgrade, since Keystone behavior and mapping syntax can shift between releases. Keep the results with the change record. Your integrator should be able to show you each test, its expected result, the observed result and the date it was last run.
What must we monitor, document and maintain after SSO goes live?
Once Keystone federation is in production, the platform team keeps it trustworthy through a fixed routine of expiry monitoring, failure logging, version-controlled configuration, retesting and access reviews. Each step ends with a record that a named owner can show an auditor or an incident responder. The sequence keeps federated access working as the identity provider, the mapping rules and OpenStack itself change.
Track certificate and client secret expiry
The platform team lists every credential the integration depends on: the SAML signing and metadata certificates, the OpenID Connect client secret, and any LDAP bind account if one is used. For each item, record the owner, the expiry date and the rotation procedure in the identity provider. Configure alerts that reach the platform on-call channel and the identity team well before each expiry, then test one alert end to end. The step is complete when every credential has a dated alert and a rotation runbook that has been walked through once.
Log federation login failures and rule misses
Enable Keystone and reverse proxy logging for the federated authentication endpoints, and pull the matching sign-in events from the identity provider. Build a dashboard that shows failed assertions, token issuance errors and users who authenticate successfully but receive no mapped groups or projects, since that last case signals a mapping rule miss. Set an alert for sudden spikes in failures. The step is complete when a deliberate test login with an unmapped user appears on the dashboard and triggers the alert.
Version control mapping rules and identity settings
Store the Keystone mapping rules, the identity provider federation settings, the protocol configuration and the role matrix in a version control repository. Export identity provider settings on a regular basis or manage them as code where the provider supports it, and document any change that cannot be exported. Require every change to pass a review by someone other than the author before it is applied to production. The step is complete when the repository holds the current configuration, the review history explains each past change, and the live system matches the repository.
Rerun the verification suite after changes
The verification suite covers a login through each enabled protocol, correct project scoping for each mapped group, role grants that match the matrix, and negative tests for users who should be refused. Rerun the full suite after every OpenStack upgrade and after every change to the identity provider or mapping rules. Planning the upgrade itself, including release choice and maintained branch timing, is covered in the OpenStack upgrades and support topic. The step is complete when the suite passes on the target environment and the results are stored with the change record.
Document the break-glass access procedure
Write a break-glass procedure that describes how a local administrative account is reached if the identity provider or federation is unavailable. The document names who may invoke it, the approval needed, where the credentials are stored, how each use is logged and how the account is disabled again. Confirm the names with the security and operations leads, and test that the account can be reached without relying on federation. The step is complete when the signed-off procedure is stored with the runbooks and the named list of approved users is current.
Review group membership and mapping coverage
On a schedule the owners agree in advance, compare the groups in the identity provider with the groups that Keystone maps to projects and roles. Look for identity provider groups with no mapping, OpenStack projects with no federated members, grants that outlive the employees or teams they were issued for, and users who hold more access than the role matrix allows. Open a tracked change for each finding and route it through the same review as other configuration changes. The step is complete when the review record lists every finding, its owner and its resolution.
What do buyers and engineers ask before building OpenStack SSO?
What drives the cost of an OpenStack SSO integration project?
The cost follows the written scope, mainly how many identity providers, protocols, projects and mapping rules are involved. Upstream Keystone is open source under the Apache License, Version 2.0, so the software license adds no line item. The paid work is design and implementation: reviewing your identity provider configuration, defining how group claims map to Keystone groups, projects and roles, wiring the integration into the cloud, and testing login paths with real users. Recurring costs are your identity team's time for group changes and your own operations staff. Ask any quote to separate one-time design, build and test effort from recurring support, and to list which identity systems and projects are included. DeployOpen issues quotes from a written scope and does not publish a price list.
How long does OpenStack SSO integration take to deliver?
The timeline depends on three things: how ready your identity provider is, how clean your group data is, and how much testing the scope includes. If your identity provider already releases the attributes OpenStack needs and the group model is agreed, the build moves quickly. If group membership lives in several inconsistent places, most of the time goes to resolving ownership and mapping decisions, which no installer can shorten. Test scope matters as well. Checking one administrator login path is far smaller than testing every project, role and region. This page does not give a duration, and DeployOpen does not publish one. Ask for a schedule that lists the readiness checks, the decisions your team must make, and the test window it assumes.
What does the client need to provide for an SSO setup?
Plan on providing four things before work starts. First, administrative access to the identity provider, or a named administrator who can register the OpenStack application, configure redirect URIs and release the required claims. Second, directory owners who can confirm group names, membership sources and who may change them. Third, a named role matrix that maps each group to OpenStack roles for each project, signed off by the people who own access decisions. Fourth, a test window with users available to log in, plus either a staging OpenStack environment or an approved maintenance period on production. Without the role matrix, mapping rules get written from assumptions, and testing reopens design questions late in the project.
Can an internal team set up OpenStack SSO without a partner?
Yes, an internal team can do it alone if it has working knowledge of both identity federation and OpenStack Keystone. The protocol configuration, whether SAML 2.0 or OpenID Connect, is covered in the upstream Keystone federation documentation. The hardest part is usually the mapping design: translating group memberships from the identity provider into Keystone groups, roles and projects so that access stays narrow and directory changes flow through without manual edits. Teams new to this often underestimate edge cases, such as users in several groups, users with no group and expired memberships. A partner helps when those skills are thin or the schedule is tight. Either way, write the role matrix first, because every other decision depends on it.
Is LDAP required for OpenStack SSO with Keystone?
No, LDAP is not required for federated login. The choice depends on where your user and group data lives. Keystone can authenticate users through a federated identity provider over SAML 2.0 or OpenID Connect, and it can also read identity data from an LDAP backend. If your groups already live in a directory and your identity provider reads from it, federation usually handles login while group claims carry the authorization data. If your identity provider does not expose groups in a usable form, you may need an LDAP backend or another claim source. Confirm with your identity team which system is the source of truth for group membership and which protocol your identity provider supports before choosing a design.
How does Keystone-to-Keystone federation differ from direct IdP federation?
In direct identity provider federation, each OpenStack cloud trusts your identity provider and maps its claims locally. In Keystone-to-Keystone federation, one Keystone acts as the identity provider for another, so the second cloud trusts the first Keystone and receives users through it. The practical difference is in trust chains and operations. Direct federation keeps one trust relationship per cloud with your identity provider. Keystone-to-Keystone adds a hop that you must operate, patch and monitor. It suits multi-region or multi-cloud setups that share a user base and want one login authority across deployments. For a single cloud connected to an enterprise identity provider, direct federation is usually the simpler design. Confirm the topology before building anything.
Which mapping rule mistakes cause the most OpenStack login failures?
The most common cause is a mismatch between the claim the identity provider sends and the value the mapping rule expects, such as a group identifier that changed format or a domain prefix that was dropped during a directory change. The second cause is a rule that matches too broadly, which grants more access than intended and only shows up when someone tests with users in several groups. The third is rule ordering, where one rule shadows another and a user receives an unexpected role set. Check the attributes your identity provider releases first. Then test one user per group with the exact claim set, and capture the mapping output. Keep the rules under version control so each change is reviewed before it reaches production.
How DeployOpen scopes, builds and hands over OpenStack SSO
DeployOpen treats OpenStack SSO and identity integration as a written, fixed-scope engagement inside your own infrastructure. We agree the identity provider, protocol, mapping rules and project model up front, then build and test the federation in your environment and document it for your team to run.
How we scope
- Engagements are fixed-scope, with the identity protocol, Keystone federation design and target OpenStack release agreed in writing before work starts.
- The written scope names which identity provider is federated, whether SAML 2.0, OpenID Connect or Keystone-to-Keystone is in use, and which LDAP backends are included.
- Scope lists the mapping rules to be written, the groups, roles and projects they map to, and the test users used to prove each rule.
How we build
- We configure Keystone federation against your identity provider in your own environment, with changes tracked in version control.
- Mapping rules are written and tested per group so federated users receive only the roles and projects their groups should grant.
- Each protocol path, including login, logout, token expiry and fallback access, is tested before the federation is handed over.
How we hand over
- Deliverables include the configuration, mapping rule files, identity provider registration details and a record of the tests run.
- We document how to add a group, change a mapping rule and rotate the trust material, so your team can make routine changes without us.
- Handover covers the runbook for troubleshooting failed logins and identifying which mapping rule matched a given user.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering federation changes after handover.
- Retainer support can cover retesting identity flows when the OpenStack release is upgraded, including between SLURP releases.
- Ask in your quote which identity changes, certificate renewals and mapping updates are included in a retainer and which are billed separately.
