Ceph SSO and identity integration

Ceph authenticates a directory user at the entry point for each surface, but it does not decide on its own which directory group becomes a Dashboard administrator, which account owns a bucket, or which role a temporary session receives. Those mappings are a separate design task. Teams should plan them with the identity owners before any integration work starts, because the authentication settings and the authorization outcomes live in different places and are changed by different people. For the Dashboard, single sign-on uses SAML 2.0. The browser is redirected to the identity provider, the user signs in there, and the identity provider returns a signed assertion to the Dashboard endpoint. The Dashboard validates the assertion against the configured identity provider metadata and then creates a session. Ceph's documented SAML settings cover the identity provider and service provider details, including which attribute carries the user name. Where OAuth2 is used instead, cephadm must run the Management Gateway and OAuth2 Proxy services, which sit in front of the Dashboard and handle the token exchange. Confirm in the Ceph Dashboard documentation for your release which SSO options are supported and how the gateway services are deployed. RGW works differently. A client presents an identity to the gateway, and RGW checks that identity against LDAP or Keystone before it authorizes an S3 or Swift request. The documentation covers both backends, but the exact LDAP search filters, group handling and Keystone token validation behavior are details to confirm for the release in use. Access to a given bucket is then decided by ownership, bucket policy and IAM-style policies, not by the directory login alone. For temporary credentials, the AWS STS-compatible API issues role sessions, and the session policy and role definition determine what the session may do. Confirm how role trust and session tags are configured for your release. The practical planning task is to write a mapping table before configuration. For each directory group, record whether it grants Dashboard administrator rights, which tenant or RGW user it corresponds to, which buckets it owns or may read, and which STS roles it may assume. Assign an owner for each row and review it when the directory changes. Ceph will not generate this table for you, and a login that succeeds does not prove that the mapping is correct. Finally, test the mapping as a separate step from the login test. Use a set of test accounts for each directory group, confirm that Dashboard roles, bucket access and STS sessions match the table, and check that removed or disabled users lose access at the identity provider and in Ceph. Record the results so auditors can compare them with the approved design.

Testing Ceph SSO is not finished when a mapped user can log in. The failure paths decide whether the integration is safe in production, so give them the same weight as the success path. Before go-live, the test plan should cover two surfaces: the Ceph Dashboard, where SSO is configured over SAML 2.0 or, when cephadm runs the Management Gateway and OAuth2 Proxy services, OAuth2, and the Object Gateway (RGW), where LDAP, Keystone or AWS STS-based access applies. Each surface needs its own cases, and each case needs an expected result written down before the test runs.

On the success side, test a user who belongs to a mapped group and confirm the role or tenant they receive is the one you designed, not a broader one. Then test denial: a user with no mapping, a disabled account in the directory, and a user whose group membership is missing the attribute Ceph expects. Denied logins should fail closed, with no partial session and no default role. Confirm the exact message and log entry the reader will see, because operations staff will rely on it during an incident.

Next, test what happens when the identity provider or directory is unreachable. Stop the IdP or block the LDAP port from a monitor or gateway host, then observe whether existing sessions keep working, whether new logins are refused, and whether RGW STS requests fail with a clear error. Also test logout and session expiry on the Dashboard, and remove a user from the group that grants access, then check whether an existing session or an unexpired STS credential still works. Those results decide your revocation window. Test STS credential expiry separately by requesting short-lived credentials and confirming that requests fail once the lifetime passes.

The break-glass path must be tested before go-live, not after the first outage. Confirm that a local Dashboard administrator account or a documented cephadm and CLI procedure works when SSO is down, that the credentials are stored under your controls, and that using them is logged and alerted. Rehearse the steps with the people who would perform them at night.

Record every case in the acceptance checklist with the test identity, the action, the expected result, the observed result and the evidence location. Ask your partner or internal team to agree the checklist before testing begins, so that a failed case is a defect to fix rather than a result to explain away. Retest any case that changes after an upgrade, a directory schema change or a certificate rotation.

Go-live is the start of identity operations, not the end of the project. Once Dashboard SSO or RGW authentication is working, four recurring tasks keep it working: reviewing group-to-role mappings on a schedule, tracking certificate and metadata expiry for each identity provider, watching failed login and denied access events, and rotating client secrets. Assign each task a named owner and a fixed review interval before the cutover, so that nobody has to rediscover them when something breaks.

Group-to-role mappings drift. Dashboard roles, such as administrator, read-only or pool manager, are granted by group membership in the identity provider, and RGW user and tenant access depends on the groups or claims your LDAP, Keystone or STS setup passes through. Review each mapping against the current directory at a set interval, and remove mappings for groups that no longer have a clear business owner. Record who approved each change, because a silent group rename in the directory can either lock administrators out or grant broader access than intended.

Certificates and SAML metadata expire on their own schedule, and an expired signing certificate or metadata file causes SSO to fail for every user at once. For each identity provider, record the expiry date of the signing and TLS certificates, the metadata URL or file, and who is notified before renewal. Confirm the renewal procedure in your own environment, including whether the identity provider publishes new metadata automatically or needs a manual upload to the Dashboard. The same applies to OAuth2 client secrets used through the Management Gateway and OAuth2 Proxy services: rotate them on a schedule, and plan the cutover so both old and new values are not needed at once in a way that breaks logins.

Failed login and denied access events are the early warning for both misconfiguration and misuse. Forward Dashboard authentication logs and RGW access logs to your central log platform, and alert on spikes in failures, logins from unexpected identity providers, and repeated denials for the same user. Decide who triages these alerts and how often someone reviews the quieter signals. Confirm with your security team which events they need retained, and for how long, because that is a policy decision rather than a Ceph default you can assume.

Every Ceph upgrade can change how authentication behaves, so identity settings must be retested after each one, not assumed to survive. This applies to the current Squid line, whose estimated end of life is October 31, 2026, and to the Tentacle release (20.2.x, estimated end of life June 1, 2027), which is the planned upgrade target described in the upgrades topic. Keep the test cases from go-live and run them on a staging cluster before every production upgrade. Handover should contain the mapping matrix, the test cases with their latest results, the owner of each identity source, and the break-glass procedure for local administrator access when the identity provider is unavailable. Store these in your change system, and update them whenever a mapping, certificate or owner changes.