Odoo SSO and identity integration

Access in Odoo is determined by the groups assigned to each user, so a single sign-on link is only as trustworthy as the group mapping behind it. Signing in successfully proves who the person is, but it does not decide what they can do. Whatever groups a user holds in Odoo, whether assigned by an administrator, set by an automated import, or carried over from a directory attribute, determine their menus, record access and administrative powers. Before you connect LDAP, Azure or Google sign-in, decide how each directory group will map to an Odoo access role, because that mapping is where most identity problems surface after go-live.

The usual design gives each Odoo access role its own directory group, such as one group for sales users, one for accounting users, and a small separate group for system administrators. Each group should have a named owner who approves membership, and that owner should be recorded somewhere your team can find during an access review. Keep the number of roles small. Many organizations start with a broad mapping and then discover that the same directory group is quietly granting more power than intended. Review who holds administrator rights on a fixed schedule and compare that list with the directory, not only with the Odoo user list, so that departures and role changes are caught in the place where they originate.

Users who sign in but get no useful access are the most common early failure. The sign-in succeeds, the user lands on an empty home screen or sees a permissions error, and the cause is usually a missing or misnamed group mapping rather than a broken connection. Test each role with a real account from each directory group before users are onboarded, and confirm that the group names in the directory match exactly what the integration expects. Plan a support path for these cases so that people do not compensate by requesting administrator rights.

Users who keep access after leaving happens when local Odoo accounts still exist next to the federated ones. A person removed from the directory can still sign in with a password set before the change, or through a local account that was never linked. Confirm whether your chosen method disables local password sign-in for federated users, decide which accounts are allowed to remain local (for example, a break-glass administrator), and include Odoo user deactivation in your offboarding checklist. Verify this with a test leaver account, not only by reading the documentation.

Directory changes often do not take effect immediately. A group added or removed in the directory may only apply at the user's next sign-in, or at the next scheduled sync, depending on the method you choose. Until then, a user may hold access they should have lost or lack access they were just granted. Confirm the sync behavior for your chosen authentication method in your Odoo version, including whether group membership is refreshed on sign-in, by a scheduled job, or only when an administrator intervenes. Document the expected delay and tell approvers and service desk staff about it so that a change is not reported as broken within minutes.

The test plan for Odoo sign-in should prove three things before go-live: that each approved sign-in method works for a real pilot user in each role, that users outside the access map are refused, and that a person removed from the directory loses access to Odoo. Run these tests against a neutralized copy of the production database or a dedicated test instance, not against live customer or payroll records. Record the expected result for each case before you run it, so the evidence shows what was checked rather than what happened to pass. Start with sign-in. For each method you enable, whether LDAP, Microsoft Azure OAuth or Google sign-in, pick one pilot user for every Odoo role that will exist in production, such as a sales user, an inventory user and an accounting user. Confirm that each one lands in the expected app menus and record rules, and that a user who should not hold a group cannot reach its menus or records. Also test a user who is not in the directory group that your mapping requires. That sign-in must be denied, and the Odoo log should show the attempt. If your configuration allows user creation on first login from a template, confirm which template is applied and that it grants no administrator rights.

Administrator accounts need their own cases. Confirm that two-factor authentication is enforced for every administrator account, including the built-in administrator if it is still active, and test that an administrator without a second factor cannot finish sign-in. Next, disable a pilot account in the directory and attempt sign-in again. The attempt should fail even if an existing Odoo session or cached token remains, so test both a new sign-in and a session that was open before the change. Then check the Odoo user record. Depending on your design, the record should be archived or deactivated, or its group memberships removed, and the user should no longer appear as an active internal user. Confirm which of these behaviors your configuration produces. Do not assume that a disabled directory account changes the Odoo record automatically unless you have tested it.

Failure behavior needs a deliberate test, because it decides what your team does at 2 a.m. Disconnect or block the directory connection in the test environment and observe what happens to sign-in. Confirm whether users see a clear error, whether existing sessions continue, and whether the administrator path still works. Decide in advance whether local Odoo login stays available for break-glass use. If it does, keep a small set of named emergency accounts with strong, separately stored credentials, enforce two-factor authentication on them, and test that they work while the directory is down. If it does not, document how an administrator restores access. For rollback, export the current authentication settings and the group map before any change, and rehearse restoring them. Your rollback plan should say who can trigger it, which services stop during the change and how you confirm sign-in has returned to the previous method.

After go-live, monitor the events that show whether the integration is behaving as designed. Track failed sign-ins grouped by user and source, because a spike can mean a misconfigured directory, a password spray attempt or a broken group sync. Watch new user creation, since unexpected accounts often reveal a first-login template that is too permissive. Review group changes made through the directory or inside Odoo, and treat any change to administrator groups as a notable event. Log administrator sign-ins with their time and source. Confirm with your team how these logs reach your security monitoring and who reviews them, and set alert thresholds with the people who own the directory.

Hand over a documentation set that someone other than the implementer can use. It should include the configuration record, covering the enabled sign-in methods, directory endpoints without secrets, two-factor settings, first-login template and break-glass policy. The group map should list each directory group, the Odoo group it maps to, and the reviewer who approves changes. Name an owner for the directory side, an owner for Odoo access and an owner for break-glass accounts, with backup contacts. Finally, include the test evidence: the test case list with expected and actual results, dates, tester names, screenshots or log extracts, and the retest record after any fix. Ask your implementation partner to confirm in writing which of these items they will deliver and which your team must produce.