Rocket.Chat SSO with SAML, OAuth and LDAP guide

Rocket.Chat SSO decides who can sign in and what they can reach

Single sign-on, directory sync, group mapping and multi-factor authentication are configured as one design, and the choices made in the first planning sessions decide how much rework follows. The typical situation looks like this: an organization runs Rocket.Chat for internal messaging, and every person who signs in must use an existing corporate account. When someone joins, changes teams or leaves, that change should happen once, in the directory, and reach Rocket.Chat without an administrator editing accounts by hand. Access removal is the requirement that matters most, because a workspace that still accepts a departed employee's credentials has failed its purpose, whatever the login screen looks like. Treat the identity design as a security control from day one, before the first user is invited.

Each of the four parts is a separate setting, and they interact. Login federation decides how a user proves identity, either through SAML or OAuth against your identity provider, or through an LDAP or Active Directory bind. Directory sync decides which accounts and attributes Rocket.Chat creates and updates, and how it handles accounts that disappear from the directory. Role assignment decides what administrators, moderators and ordinary members can do inside the workspace. Channel membership decides what each person sees after sign-in. These layers can disagree. A group that grants a role may also be the group that adds someone to a private channel, and a login path that bypasses sync can leave an account active after the directory has removed it. Write down which system is the source of truth for each layer before you configure any of them.

Confirm your Rocket.Chat plan before you design group rules. The free Starter plan allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication, so a small team can test the core login flow on it. The pricing page, however, lists LDAP and SAML user group mapping as features of paid plans, and group-based role or channel assignment depends on that mapping. If your design relies on directory groups to decide who is an administrator or which channels people join, ask Rocket.Chat to confirm in writing which plan includes each capability you need, and verify the same thing on the version you will deploy before you build rules around it.

Decide these items before implementation starts: which identity provider is authoritative, which attributes must match between systems, which directory groups map to which roles and channels, who approves changes to those mappings, whether MFA is enforced by the identity provider or by Rocket.Chat, and how administrators sign in if the identity provider is unavailable. Test each path with non-production accounts for a new hire, a user who changed groups and a user removed from the directory, then record what Rocket.Chat shows afterward. DeployOpen implements this integration inside your own cloud accounts, data centers or private network under a written scope, so the mapping rules, test cases and acceptance checks are agreed in that document before any configuration changes are made.

Which directory, login and admin settings the integration depends on

Six components decide who can sign in, how they prove identity, what they can do after sign-in, and which channels they join. They depend on each other: a directory change can alter roles and room membership, and a login provider fault can lock out the administrators who would fix it. Review them together before go-live and confirm each setting name in the admin console for your installed version.

LDAP or Active Directory connection and sync

The directory connection is the source of truth for which users exist in Rocket.Chat and, depending on configuration, which groups they belong to. Check the bind account, the search base and the user filter, because a filter that is too narrow silently leaves people out and one that is too broad creates accounts for contractors and service identities. Confirm how often sync runs and whether accounts disabled in the directory are deactivated in Rocket.Chat. If the bind account's password expires or its permissions change, sync stops, and sign-in failures can look like user errors.

SAML or OAuth login provider

The login provider handles the sign-in itself. Rocket.Chat trusts the assertion or token it receives, so the entity or client identifiers, callback URLs, signing certificate and attribute names must match exactly on both sides. A mismatch usually produces a login loop or an account created without a usable email address. Schedule certificate renewal before expiry, since an expired signing certificate blocks sign-in for every user who depends on it. Confirm the supported protocol options and attribute mapping fields in the admin console for your version.

Multi-factor authentication enforcement

MFA decides how a password or SSO sign-in is confirmed with a second factor. Decide where it is enforced: in your identity provider, in Rocket.Chat, or in both, because enforcing it twice can prompt users twice or lock them out. Also decide whether enforcement applies to everyone or by role, and how users re-enroll after losing a device. Test every sign-in path, including the mobile and desktop clients, before rollout. Confirm the available MFA options and enforcement settings in the admin console for your installed version.

User to role and group mapping

Directory groups can drive Rocket.Chat roles such as administrator, moderator or a custom role, so a group change in the directory changes what a person can do. Map only groups that are documented and owned by someone accountable, and keep a short list showing which group grants which role. The main risks are a broad group, such as all staff, being mapped to an administrative role, and a removed group leaving users with privileges they should have lost. Confirm with Rocket.Chat which plan includes group mapping before you design around it.

Channel membership rules

Membership rules can tie channels to directory groups, so new joiners reach the right rooms and leavers are removed from them. Decide which channels are open, which are private and which are filled automatically, because auto-joining a large group can place people in channels holding history they should not see. Check whether removed users keep access to past messages and files, and whether channel owners can still change membership by hand. Confirm the exact membership and auto-join options in the admin console for your installed version, then pilot them with one group before enabling them workspace-wide.

Local administrator accounts outside SSO

Keep at least one local administrator account that does not depend on the identity provider or the directory, so you can recover access during an outage, a certificate failure or a faulty mapping. Store its credentials under your privileged-access process, require MFA on it, and confirm it still signs in after each configuration change. Log and review each use. If every administrator is an SSO user and the provider is unavailable, no one can correct the settings that caused the problem. Confirm how local accounts and password policy are configured in the admin console for your version.

Choosing between LDAP sync, SAML and OAuth for Rocket.Chat

This table compares LDAP or Active Directory authentication, SAML single sign-on, OAuth single sign-on and a combined directory plus federated login model for Rocket.Chat. Read each row as a fit test: match your existing identity estate first, then weigh the ongoing credential and outage work that option adds.

Option	When it fits	Operational cost	Failure during identity outage
LDAP or Active Directory authentication	Administration is AD-centric, users already sign in to Windows and other directory-backed apps, and Rocket.Chat is on the same network as domain controllers	A bind account with read access to the user search base must be created, scoped, password-rotated and monitored. Directory group changes must be checked against Rocket.Chat role mapping after each change	Users who depend on the directory cannot sign in if the LDAP endpoint is unreachable, unless local fallback credentials are kept and documented
SAML single sign-on	A cloud or on-premises identity provider already handles other business apps and is the system of record for MFA and conditional access	Signing certificates expire and must be rotated in both the identity provider and Rocket.Chat. Metadata or entity IDs change need coordinated updates. Attribute mapping for username, email and groups must be kept aligned	Sign-in stops for all federated users during an identity provider outage. Confirm how existing sessions and any local admin account behave in your configuration
OAuth single sign-on	The identity provider supports OAuth or OpenID Connect and your team already manages client registrations for other internal apps	Client secrets expire and must be rotated. Redirect URIs must match the deployed Rocket.Chat domain exactly, so a domain change requires a registration update. Claim mapping for groups depends on the provider	Same dependency as SAML: federated users cannot sign in while the provider is down. Confirm token lifetimes and refresh behavior with your provider
Combined model: directory supplies accounts, federated provider handles login	Groups live in a directory, but the organization wants MFA and sign-in policy enforced at a cloud or federated identity provider	Two systems must stay in step: directory account lifecycle and federation configuration. Troubleshooting spans both, so runbooks and owners must be named for each	Failures can occur at either layer. Map each failure mode to a recovery step before go-live rather than assuming one system covers the other
Rocket.Chat group mapping and MFA location	Group-based channel access and roles are required, and the team needs to know where MFA is enforced	Group to role mapping is a paid-plan capability in the pricing materials, so confirm your plan before designing around it. MFA may be enforced in Rocket.Chat or at the identity provider, and the two choices change support work	If MFA is enforced only at the provider, confirm what happens to Rocket.Chat accounts during provider maintenance windows

How to connect Rocket.Chat to your identity provider, in order

This sequence connects Rocket.Chat to your directory or identity provider in an order that keeps sign-in working throughout the change. Each step ends with a check you can record, so the pilot and cutover decisions rest on documented evidence.

Confirm the version, plan and features
Record the installed Rocket.Chat version and confirm it sits inside its support window, because versions past end of life receive no security fixes and can lose connections to the official mobile and desktop clients. Confirm the plan covers each feature you need. LDAP and Active Directory authentication, single sign-on and multi-factor authentication are listed for the free Starter plan, but LDAP and SAML user group mapping is listed on the paid plans, so verify that entitlement in your license before designing role mapping. Confirm MongoDB is version 8.0 or later and runs as a replica set. Done when these details are written into the change record and an administrator can open the workspace administration screens for each feature.
Inventory identities, groups and required attributes
Export the directory objects Rocket.Chat depends on: the users in scope, the groups that will drive roles and channel membership, and the attributes needed for login, display name, email and group lookup. Check that each attribute is populated for every in-scope account, because a missing email or username attribute causes failed logins or duplicate accounts later. Agree with the identity team who owns each group and whether nested group membership must be expanded. Done when you hold a one-page list of groups, attributes and owners signed off by the directory team, and the count of accounts returned by your directory query matches the expected population.
Create a least-privilege bind account and staging application
In a staging environment, create a read-only directory account that Rocket.Chat uses to search, and grant it access only to the containers that hold in-scope users and groups. For SAML or OAuth, register a separate application in the identity provider that requests only the attributes and scopes the mapping needs. Store the bind password in your secrets manager and keep it out of configuration files that move between environments. Done when a directory query through the bind account returns the expected objects, and a write attempt or a read outside the permitted containers is denied.
Configure LDAP or Active Directory and verify search
In staging, enter the directory host, port and TLS settings, then set the base search path and the user and group filters. Sign in with one known test user from the intended pilot group. Confirm the search returns that account with the expected username, email and display name, and that group lookup returns the membership you recorded in step two. Check that a disabled directory account cannot sign in, and that a user outside the search base produces no match. Done when the test login succeeds, the user profile shows the expected name and email, and the out-of-scope check returns no account.
Configure SAML or OAuth with attribute mapping
Set up the single sign-on connection using the identity provider metadata or client settings. Set the callback URL to the public hostname served by your TLS reverse proxy, matching the scheme and path the identity provider expects. Map the identifier, email, name and group claims to the Rocket.Chat fields recorded in step two. Confirm the reverse proxy forwards the original host and protocol headers, so redirects do not point at an internal address. Done when a test user completes sign-in through the identity provider, the login links to the existing directory identity, no duplicate account appears, and the group claim is visible in the user profile.
Map groups to roles and channels, then set MFA
Map a small set of directory groups to Rocket.Chat roles and default channel membership. Start with one or two roles, and keep administrator rights limited to named owners. Then set the multi-factor authentication policy, choose which identities it applies to, and test enrollment with a test account on a device you control. Done when a test user in a mapped group shows the expected role and channels, an account outside the mapped groups holds no elevated role, and both enrollment and a second-factor challenge complete successfully on the test account.
Define break-glass access and pilot with one group
Create a break-glass administrator account that is local to Rocket.Chat, with a strong unique password and second-factor devices held by named people. Exclude this account from directory-driven rules, store its credentials in a sealed and audited location, and test that it signs in during a simulated identity provider outage in staging. Then enable the new sign-in configuration in production for one pilot group only. Done when the break-glass login succeeds in the outage test, a user outside the pilot group cannot complete single sign-on while the pilot restriction is active, and pilot users sign in with the correct roles.
Cut over to all users and monitor sign-in
After the pilot closes with no unresolved sign-in or mapping issues, expand the configuration to the full user population during an agreed change window. Keep the break-glass account and the previous sign-in path documented until the cutover is confirmed stable. Review authentication logs, failed sign-in counts and group assignments through the first operating cycle, and confirm that new joiners and leavers flow through the directory without manual steps. Done when a test removal of a leaver account blocks access, the open pilot issues are closed, and the operations owner accepts the monitoring routine in writing.

How identity setup changes by plan and deployment model

Starter is the simplest identity setup because the core sign-in methods are included in the free plan. Rocket.Chat's plan documentation lists LDAP and Active Directory authentication, single sign-on and multi-factor authentication for workspaces of up to 50 users. You configure these in the administration console, and most of the work is directory and identity provider settings. The main constraint is the user count, so the design starts from a headcount that must stay under the limit.

Points for the Starter build:

Directory bind: connect LDAP or Active Directory with a service account and a search base agreed with your directory team.
Single sign-on: confirm which protocol your identity provider supports, since SAML and OAuth setups both need a callback URL that matches the workspace address.
MFA scope: decide whether multi-factor authentication applies to directory users, local accounts or both.
Group handling: LDAP and SAML group mapping is listed for paid plans, so confirm how Starter assigns roles to directory groups before you rely on it.
User ceiling: track active accounts against the 50-user limit, because growth beyond it changes the plan decision.

Before go-live, test a login from one account in each access group and confirm the current user count against the plan limit.

What drives SSO integration effort and cost

This table lists the factors that change how much work a Rocket.Chat SSO integration takes, and what keeps each one manageable. Read each row as a decision point: the effort column shows what raises the workload, and the control column shows what your team can do to hold it down. The main takeaway is that mapping rules, group sources and test rounds usually matter more to effort than the number of login methods.

Driver	How it raises effort	What keeps it down
Identity sources	Each source adds its own attribute schema, login path and failure modes, for example LDAP or Active Directory alongside SAML or OAuth.	Limit to one authoritative directory for users, and use the others only where a specific application needs them.
Directory size and group nesting	Nested groups and large user counts make sync scope, filter design and performance testing more involved.	Scope sync with a filter to the users who need Rocket.Chat, and flatten group structures before integration.
Group-to-role and channel rules	Each rule needs a documented owner, a test case and a review when org structure changes, and overlapping rules are hard to debug.	Keep the rule set short, map to a small number of Rocket.Chat roles, and prefer channel membership through a single group source.
Identity provider applications and environments	Separate applications for production, staging and any test tenant each need their own redirect URIs, certificates and claim settings.	Use a staging Rocket.Chat instance that mirrors production configuration, and template the provider settings for each environment.
Required attributes and custom claims	Each attribute Rocket.Chat must read, such as email, username or department, needs a source, a format and a fallback when it is missing.	Agree the attribute list in writing before build, and request only the claims the workspace actually uses.
MFA method and enrollment policy	Choosing between authenticator apps, hardware keys or other factors, plus grace periods and enrollment for users outside the directory, adds design and support work.	Pick one primary factor, define the enrollment window in advance, and confirm the chosen method works with your identity provider.
Compliance evidence needs	Assessors may ask for proof of mapping logic, access reviews, MFA enforcement and change records, which adds documentation and export steps.	Define the evidence list at scoping, and capture configuration exports and test results as part of each change.
Pilot and cutover test rounds	Each round of pilot users, edge-case logins and cutover rehearsal repeats work and can reveal new mapping gaps.	Run a defined pilot group with agreed exit criteria, and rehearse cutover in staging before the production change window.

Protecting bind accounts, certificates and break-glass access

Single sign-on moves trust into a small set of credentials: a directory bind account, signing certificates, OAuth client secrets and the administrator accounts that can still sign in when the identity provider fails. The cards below cover how each one is scoped, stored, rotated and tested in a self-hosted Rocket.Chat deployment. Confirm which of these options your installed version exposes before you design around them.

Least-privilege directory bind account

Rocket.Chat uses a bind account to query the directory for user lookups and group membership during LDAP or Active Directory sync. Create a dedicated read-only service account limited to the organizational units that hold Rocket.Chat users, and deny it write and password-reset rights. Confirm the password rotation method your version supports, and schedule rotation with a documented update to the Rocket.Chat LDAP settings so sync does not fail silently.

LDAP over TLS and certificate trust

Bind credentials and user attributes must not cross the network in cleartext, so the LDAP connection should use TLS with the directory's certificate chain trusted by the Rocket.Chat server. Confirm whether your version validates the certificate hostname and accepts a custom certificate authority bundle. Test the connection with an invalid certificate in a staging environment to confirm that sign-in fails closed.

SAML signing and encryption certificate rotation

The SAML signing certificate in Rocket.Chat must match the certificate registered with the identity provider, and an expired or mismatched certificate blocks every SAML sign-in at once. Record the expiry date of each signing and any encryption certificate, set reminders well before expiry, and plan the overlap period where both old and new certificates are accepted. Confirm with your identity provider how metadata is refreshed and whether it can publish a second certificate.

OAuth client secret storage

The OAuth client secret for each identity provider should live in a secrets manager or the orchestration platform's secret store, not in the Git repository, Helm values files or the admin settings export. Limit read access to the people and services that deploy Rocket.Chat, and rotate the secret when staff with access change roles. Confirm whether your version reads secrets from environment variables or only from the admin console.

MFA enforcement and account recovery

Enforcing multi-factor authentication for Rocket.Chat users decides whether a stolen password is enough to read conversations. Decide which roles must enroll, how users recover a lost authenticator, and who can reset that factor without bypassing the identity provider's own controls. Confirm which MFA methods your installed version supports for LDAP and SAML users, since enforcement can differ by login method.

Session termination when a user is disabled

Disabling a user in the directory does not automatically end sessions that are already open in Rocket.Chat unless sync and session handling are configured for it. Test this on a non-production account: disable the user, then confirm that existing web and mobile sessions stop accepting requests within the window your policy requires. Document the manual steps to revoke sessions, and confirm whether your version can deactivate users through LDAP sync.

Tested break-glass administrator outside SSO

Keep at least one local administrator account that does not depend on LDAP, SAML or OAuth, so the workspace can be recovered if the identity provider, certificate or directory is unavailable. Store its credentials in a sealed, access-logged vault, require MFA where the version supports it, and restrict its use to documented recovery events. Test sign-in through this account on a schedule, and confirm it still works after each identity change.

How to test that Rocket.Chat SSO works and fails safely

Run a written test matrix before any user depends on the Rocket.Chat integration, and give every row a pass or fail result, a named owner and a date. The matrix should cover a successful login for a user who maps to the right role, a denied login for a user who exists in the directory but maps to no allowed group, and a disabled or removed directory account that loses access. Add a group removal that should change the user's role or channel membership, MFA enrollment, a lost-device recovery path, login through the official desktop and mobile clients, behavior during a short identity provider outage, and a check that the break-glass administrator can still sign in. Each case needs an expected result written down before testing starts, so the outcome is judged against the design rather than against whatever happens on the day.

For each case, read two logs side by side: the identity provider sign-in record and the Rocket.Chat authentication and administration records for the same user and time window. A denied login for an unmapped user should show a successful directory or SAML authentication followed by a rejection on the Rocket.Chat side, and the reason should be traceable. For a disabled account, confirm when the identity provider revoked access, when Rocket.Chat stopped accepting new logins and whether existing sessions ended within the session lifetime you configured. For a group removal, record the role and channel memberships before and after, and note whether the change took effect at the next login or at the next directory sync. Confirm with your edition which audit views and log retention apply, because paid plans list tamper-evident audit trails and your free or Starter setup may expose fewer records.

Client tests must run on a supported Rocket.Chat release. Rocket.Chat states that unsupported versions may lose the ability to connect with the official mobile and desktop clients, so a pass on an out-of-support server proves little about what users will experience. Test MFA enrollment and the lost-device recovery path with the same client builds your users will install, and confirm how a user recovers access without the administrator resetting every factor by hand. For the identity provider outage test, stop or block the directory or SAML endpoint for a short, planned window and record which existing sessions continue, which new logins fail and what message users see. For the break-glass administrator, confirm that a local account exists outside SSO, that its credentials are stored under dual control, that its MFA method is documented and that a sign-in has been performed in the test window without relying on the identity provider.

Keep evidence in a form an access reviewer can follow without a walkthrough. Retain the completed matrix with expected and actual results, timestamps in one time zone, redacted log excerpts from both systems, before and after snapshots of group-to-role and channel mappings, screenshots or exported configuration of the SAML, OAuth or LDAP settings, and the sign-off record from the approver who accepted each failure mode. Store the matrix with the change record for the release that was tested, and repeat the relevant rows after every Rocket.Chat upgrade and after any change to identity provider groups. DeployOpen can prepare these systems, controls and evidence for an assessment, but independent auditors decide whether the evidence meets the framework you are assessed against. Ask your auditor early which artifacts they expect.

What to monitor, rotate and document after go-live

Go-live is the start of the identity work, not the end of it. Certificates and secrets expire, directories change, and Rocket.Chat versions reach end of life, so each of these needs an owner, a schedule and a check that runs after every change.

Track certificate and secret expiry

Record the expiry date of the SAML signing and encryption certificates, the TLS certificate on the Rocket.Chat endpoint and the OAuth client secrets, and set reminders well before each date. An expired SAML signing certificate or OAuth secret stops sign-in for every user at once, so confirm with your identity provider how it handles certificate rollover and whether it can hold two valid certificates during the change.

Monitor directory sync and login failures

Watch LDAP or Active Directory sync results and authentication failures in the Rocket.Chat administration logs and your identity provider logs. Look for accounts that fail to sync, disabled accounts that remain active, and a sudden spike in failed logins, which can point to a broken bind account, a changed search base or an attack. Confirm which sync interval and error reporting your version provides.

Review group mappings on a schedule

Review the mapping of directory groups to Rocket.Chat roles and channels on a fixed schedule and after every reorganization, merger or change in team ownership. Stale mappings can leave former staff with access to private channels or block new joiners from the channels they need. Compare the live mappings against the approved mapping matrix and record each change with a reviewer and a date.

Keep identity connectors on the upgrade cycle

Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life a version receives no security or bug fixes, and cloud services such as the push notification gateway stop working. Retest the SAML, OAuth and LDAP connectors on each supported release before it reaches production, because connector behavior can change between versions. Confirm the end-of-life date for your current version before you plan the next upgrade.

Document the identity runbook

Keep a runbook that records the SSO and directory configuration, the group to role and channel mapping matrix, the break-glass procedure for local administrator access when the identity provider is down, and a named owner for each component. Store it where the on-call team can reach it during an outage, and test the break-glass path at least once after go-live. Confirm with your security team how break-glass access is approved and logged.

What buyers ask before bringing in help with Rocket.Chat SSO

How much does Rocket.Chat SSO implementation cost?

Cost follows from a written scope, because DeployOpen does not publish a price list. The quote usually covers discovery of your identity sources, LDAP or Active Directory sync, SAML or OAuth setup, group to role and channel mapping, MFA policy, staging validation, pilot support and handover documentation. Labor is the partner's cost. The Rocket.Chat subscription is a separate cost, quoted by Rocket.Chat, and your identity provider licensing is one you already hold. Build and testing are one-time costs, while the plan subscription and any ongoing support retainer recur. The main cost drivers are the number of identity sources, the complexity of group rules, the number of test rounds and whether a pilot runs. Ask for line items, stated assumptions, client dependencies and a change process.

How long does a Rocket.Chat SSO project take?

Duration depends on the number of identity sources, the complexity of mapping rules and the number of test rounds, and the timeline is confirmed in the written scope. A single directory with a simple group model moves faster than several directories with nested groups and exceptions. Delays usually come from waiting on identity provider changes, approvals for the pilot group, or fixes found during testing. Ask the partner to list which dependencies sit with your team, such as application registration in the identity provider, certificate issuance and access to a staging environment. Ask for the number of test rounds included in the scope and what happens if a round fails.

Can our internal team set up Rocket.Chat SSO without a partner?

Yes, if your team has administrators for both your identity provider and Rocket.Chat, plus time for testing. The work involves directory administration, registering a SAML or OAuth application, handling certificates, configuring Rocket.Chat authentication settings, and understanding how TLS and the reverse proxy affect login. The most common risks are locking administrators out, misconfigured attribute mapping and group rules that grant the wrong access. Teams with a small platform group often bring in a partner for design review, the mapping rules or the pilot, while keeping day-to-day administration in-house. Whichever route you take, test with non-administrator accounts before rollout.

What does Rocket.Chat SSO work need from our side?

The work needs administrative access to your identity provider, directory details such as base distinguished names and a read-only service account, and attribute names for users and groups. You will also need a group design that states which directory groups map to Rocket.Chat roles and channels, a staging environment that matches production closely enough to test logins, and a pilot group of real users who can report problems. Name an approver for mapping decisions, set a change window for the cutover, and provide test accounts for each role. Missing items are a common cause of schedule slips, so confirm them in the written scope before work starts.

Does SAML group mapping in Rocket.Chat require a paid plan?

Rocket.Chat's pricing page lists LDAP and SAML user group mapping among the features of its paid plans, while its free Starter plan includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication. Confirm the plan with Rocket.Chat against the exact features you need before you design the mapping, because plan contents can change. Ask for written confirmation of which plan includes group mapping for SAML and whether any of your groups depend on it. If group-driven role assignment is a requirement, the plan decision should come before the scope is written, since it affects cost and the design.

Does DeployOpen certify our Rocket.Chat deployment for compliance?

No. DeployOpen plans, implements and documents systems and prepares the controls and evidence that a compliance assessment will examine. Independent auditors and certification bodies issue audit reports, attestations and certifications. For SSO, useful evidence includes the MFA enforcement settings, the group mapping rules with their change history, access review records, administrator account lists and the test results from the pilot. Ask your auditor early which evidence they expect, so the implementation is documented to match it. Agree in the written scope who produces each artifact and where it is stored.

What should we retest for SSO after a Rocket.Chat upgrade?

Retest login flows after every upgrade, including SAML or OAuth sign-in, LDAP or Active Directory sync, group mapping, MFA prompts and the official mobile and desktop clients. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and after end of life a version gets no security or bug fixes. Staying on a supported line keeps SSO patched, but each upgrade can still change how authentication settings behave. Keep a set of test accounts for each role, record the expected results, and include the identity provider configuration in your change process. Confirm the upgrade and testing responsibilities in the written support scope.

How DeployOpen scopes, builds and hands over Rocket.Chat SSO

DeployOpen plans, builds and hands over Rocket.Chat identity integration inside your own infrastructure, from LDAP or Active Directory sync through SAML or OAuth sign-on and MFA. Each engagement starts with a written, fixed scope that names the identity provider, the login methods and the role and channel mappings to be delivered.

How we scope

The written scope names your identity provider, directory layout, and the login methods your Rocket.Chat plan includes.
It lists the group to role and channel mappings, with the owner who approves each mapping before build starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

Configure LDAP or Active Directory sync so users and groups stay aligned with the directory after go-live.
Set up SAML or OAuth single sign-on against the identity provider's metadata and callback settings, tested in staging.
Enable multi-factor authentication and map groups to Rocket.Chat roles and channels, then test each permission path.

How we hand over

Deliver a runbook covering sign-on flows, mapping tables, fallback local admin access and troubleshooting steps.
Walk your administrators through group changes, certificate or secret rotation, and how new joiners and leavers are handled.
Provide test records for sign-on, MFA enforcement and group mapping, for your team to review against its own controls.

How we support

Ongoing support can run as a retainer covering Rocket.Chat upgrades, directory changes and identity provider certificate renewals.
Plan upgrades inside the supported version window, since unsupported releases can also lose compatibility with official mobile and desktop clients.
Schedule access reviews of mappings and admin accounts with your identity team, and confirm the scope before any change.