Redmine LDAP and SSO integration

Testing Redmine single sign-on is not finished when the first login succeeds. The test plan should prove that each directory group lands on the right role, that a disabled account stops working at once, that wrong passwords and lockouts behave as policy requires, and that failures leave Redmine in a safe state. Write each case with an expected result before the test runs, and record which layer made the decision: the directory, the LDAP authentication source inside Redmine, the SSO plugin, or the authenticating reverse proxy. That record is what lets the team tell a configuration error from a design gap. Start with the happy path and the negative paths that matter most. Log in once with a test account from each directory group that maps to a Redmine role, and confirm the role, project membership and visible projects match the mapping. Then disable or remove a test account in the directory and attempt a login. Also test a wrong password several times to confirm the lockout threshold and the message a user sees. Check the first login of a brand-new directory user and confirm exactly one Redmine account appears, with no duplicate created when the user later signs in through a second path. Finally, move the same test user into a different group, log in again, and confirm the role change applies. Ask whether role changes take effect at next login or on a sync schedule, because the answer determines how long a removed privilege can persist.

Check API access separately from the browser flow. The Redmine REST API must be enabled by an administrator, and it accepts HTTP basic authentication or a per-user API key sent as a parameter or in the X-Redmine-API-Key header. Confirm with the plugin vendor or the proxy team whether an API key still works when the browser login is blocked by SSO, whether basic authentication passes through the proxy at all, and whether a disabled directory account also loses its API key access. Do not assume any of these. Record the answers in the test plan, because they decide which service accounts and integrations must be reviewed when a user leaves. Logout needs its own test. Confirm that signing out ends the Redmine session and, where the plugin or proxy supports it, the single sign-on session at the identity provider. Open a second browser, sign in there, and check whether the first sign-out affects it. Ask the vendor or proxy team whether back-channel logout is supported, how long an idle session lasts, and whether the Redmine session cookie is invalidated server side. These are questions for the platform owners, not facts to assume from the product name.

Run failure drills in a non-production copy that matches production authentication settings. Make the directory unreachable by blocking the LDAP or identity provider address at the firewall or stopping the service, then confirm what users see and whether existing Redmine sessions keep working until they expire. Expect that some sessions continue because Redmine does not necessarily query the directory on every request. Verify this with the plugin vendor or proxy team rather than relying on the expectation. Confirm also that new logins fail closed, with no fallback to a local password that bypasses the directory unless that fallback was deliberately approved. Test certificate expiry next. Use a test certificate with a short validity period on the identity provider or the LDAPS endpoint, let it lapse, and observe whether logins fail with a clear error and whether administrators receive an alert before expiry. Record the renewal steps and who owns them. The drill should also confirm how the reverse proxy handles an expired or mismatched certificate on its upstream connection, since that behavior is often different from the browser-facing certificate.

Decide in advance what the team does with existing sessions after a failure drill. Options include ending all sessions on a forced change, relying on a short idle timeout, or accepting a defined window of continued access. Each option has a cost in user disruption and a risk in delayed revocation, and the choice belongs to the security owner, not the test team. Document the chosen behavior and test it, so a future upgrade or plugin change that alters it is caught. Finish with a short evidence pack: the test case list, expected and actual results, screenshots or logs for the disabled account and lockout cases, and the written answers from the vendor or proxy team. Keep the list with the change record. Testing once at go-live is not enough, so schedule the same cases after each Redmine upgrade and each plugin or proxy update, because compatibility on Redmine 7.0 and later versions depends on the specific plugin release you run.

The operations team owns the Redmine LDAP and SSO integration from the day it goes live, and the first job is watching the directory connection itself. Redmine's native LDAP authentication depends on a live bind to the directory, so the team should alert on failed binds to the directory server, on timeouts against the domain controllers or LDAP servers named in the authentication source, and on a sudden rise in failed login attempts. A spike in failures can mean a directory outage, a changed service account password, a certificate that has expired, or a password-spraying attempt against Redmine accounts. Log entries from the Redmine application server and from the directory side should be reviewed together, because either log alone may not show the cause. Confirm with your directory team which events they already collect and which ones must be added for this integration.

Redmine can create user accounts on the fly the first time a directory user signs in, so the team also owns the list of those accounts. Review newly created users on a regular schedule and compare them against the directory groups that are meant to have access. Pay attention to the accounts that receive administrator rights, the accounts that land in groups mapped to project roles, and any account whose directory entry is disabled or missing. Deprovisioning is the other half of this work. When a person leaves, disabling the directory account stops new sign-ins, but it does not remove existing Redmine memberships or assigned issues. Agree in advance who locks or deletes the Redmine user, who reassigns open issues, and how quickly that happens. Ask your partner or internal team to show how the chosen plugin or reverse proxy handles a disabled directory account, because behavior differs between setups.

Each Redmine upgrade and each plugin update requires a new test of the integration. The upgrade guide calls for copying configuration, uploads and third-party plugins to the new installation, then running the database migration and the plugin migration task before clearing the cache and restarting. The SSO plugin is one of those third-party plugins, so it must be rechecked every time: confirm that it is compatible with the target Redmine and Ruby versions, that its migrations completed, that sign-in through the SSO path still works, that group-to-role mapping still applies, and that LDAP sign-in for fallback accounts is unaffected. If the SSO layer is an authenticating reverse proxy rather than a plugin, the same test still applies to the proxy headers and the Redmine settings that trust them. Do not treat a successful application start as proof that authentication works.

Backups for this integration need to cover more than the database. Keep a copy of the Redmine configuration files, the authentication source settings, the LDAP bind account details held in a secrets store, the SSO plugin configuration and its certificates or client secrets, and the reverse proxy configuration if one is used. Store these with the database and uploaded files, and test a restore into a non-production environment at least once after the integration is configured. Documentation is the last part of the handover. Write down the group-to-role map, which directory groups grant which Redmine global and project roles, and who approves changes to it. Write a runbook for directory outages that states what users see, which fallback accounts exist, who can enable them, how they are audited, and how normal sign-in is restored. Review both documents after every upgrade and after any change to the directory structure.