How do you add BigBlueButton SSO with Greenlight and Keycloak?
Greenlight v3 accepts external authentication through OpenID Connect, configured with environment variables, and Keycloak can sit in front of it to add SAML, Microsoft or Google logins. That combination is the usual answer for a self-hosted BigBlueButton service where staff and students already have a corporate or school identity provider and want one sign-in rather than a separate Greenlight password. The Greenlight configuration is the small part of the work. The harder part is deciding who gets in, with which role, and how the identity provider, the Greenlight server and the learning management system agree on that. The design has two paths. Users who join meetings through Moodle or Canvas usually sign in through the LMS and never touch Greenlight, so the LMS connection and its launch method carry their identity. Users who create rooms directly in Greenlight sign in through OpenID Connect. Confirm early which population matters most for your institution, and which groups need the Greenlight account at all. Teachers who only join class sessions may need no Greenlight account, while administrators who manage rooms will. The work is harder than it looks for three reasons. First, the BigBlueButton API shared secret must never reach a browser, so the design has to keep token exchange and any server-side calls on the server. Second, identity mapping needs agreement with the identity owner: which claims identify a person (email is common, but confirm it is unique and stable in your directory), which groups map to Greenlight roles, and what happens when someone leaves. Third, the change touches the BigBlueButton server, the identity provider and the LMS at the same time, so each owner needs a test plan before go-live. The supported base for BigBlueButton 4.0 is a clean Ubuntu 24.04 64-bit installation, and in-place upgrades from 2.6, 2.7 or 3.0 are not supported. Plan the SSO work on that clean server, not on an older host you hope to upgrade. The SSO setup is only as good as the server it sits on: a valid hostname for SSL, correctly reachable TCP 80 and 443, the UDP media range open, and an up-to-date operating system all affect whether sign-in works reliably. Confirm the exact client registration, redirect URI and certificate requirements against the current Greenlight and Keycloak documentation before you build.
Which components carry the login path in a BigBlueButton SSO build
A BigBlueButton SSO build involves more than one login system. Each component below holds a different piece of identity, session or configuration state, and the trust boundaries sit where one component hands a user or secret to the next.
BigBlueButton server and API secret
The BigBlueButton server runs the meeting engine and exposes an API that every front end or LMS calls. Each API request must carry a checksum computed with a secret shared with the server, so that secret is the most sensitive credential in the build. Confirm which checksum algorithm your branch uses by default and which legacy options remain enabled, and confirm that the secret never appears in a page a browser can read.
Greenlight v3 and its OIDC settings
Greenlight v3 is the room and user front end. It stores local user accounts, room settings and sessions in its own database, and its external authentication is configured through environment variables that point it at an OpenID Connect provider. Before writing any configuration, confirm the Greenlight version bundled with your BigBlueButton branch and the exact variable names in the current Greenlight v3 external authentication documentation, because names change between releases.
Keycloak as the identity broker
Keycloak sits between Greenlight and the upstream identity providers. Its realm stores users it has federated, client registrations for Greenlight, and the client secret Greenlight uses to exchange codes for tokens. Keep the Greenlight client confidential, restrict its redirect URIs to your exact Greenlight hostname, and treat realm exports as sensitive because they can contain secrets.
Upstream SAML, Microsoft and Google providers
Keycloak connects to SAML identity providers, Microsoft Entra ID or Google as external identity providers. Authentication happens at the upstream provider, so the trust boundary is the federation agreement: the signing certificates, metadata and attribute mappings Keycloak accepts. Ask your identity team who controls those certificates, how they rotate, and which attributes Keycloak maps into Greenlight user records.
LMS launch through LTI or integration
Moodle and Canvas do not need Greenlight to sign their own users in. Instead, the LMS launches meetings through LTI or its own BigBlueButton integration, and the LMS session becomes the identity source for those users. Confirm which launch method your LMS version supports, which LTI shared secret or key pair is in use, and whether LMS users also need Greenlight accounts, since that determines which login path they follow.
Trust boundaries and where state lives
Each component stores a different kind of state: users and rooms in Greenlight, federated users and client secrets in Keycloak, meeting state and the API secret on the BigBlueButton server, and session records in the LMS. Map these before go-live. Ask which system is the authoritative source for each user attribute and who can revoke access in each one, so that disabling a person in the identity provider also ends their meeting access.
Which identity path fits your users: Keycloak brokering, direct OpenID Connect or LMS sign-in
This table compares three ways to sign users into Greenlight v3 on a self-hosted BigBlueButton server, plus the account duplication that comes from mixing them. Read each row for when the path fits, what it adds to daily operations, and what the identity owner must confirm before build starts. The main takeaway is that Keycloak adds a service to run and administer, so it should be chosen only when several providers or future providers need to be supported.
| Path | Fits when | Operational cost | Confirm with identity owner |
|---|---|---|---|
| Direct OpenID Connect (no Keycloak) | One existing provider that supports OpenID Connect, with all Greenlight users in that directory. | Greenlight environment settings only, with no broker to patch. Token lifetimes and logout behavior come from the provider and Greenlight. | Client registration, redirect URI, required claims, token lifetimes and who holds the client secret. |
| Keycloak brokering | Several providers such as SAML, Microsoft or Google, or providers you expect to add later. | A Keycloak service to patch, realms and clients to administer, and token lifetimes to tune. Expect more support for wrong-provider sign-ins. | Each provider's metadata, certificate rotation, attribute mapping, and which users each provider covers. |
| LMS sign-in (Moodle or Canvas) | Moodle or Canvas users who join from the course and need no Greenlight account. | LMS integration to configure and retest after LMS and BigBlueButton updates. Users who open Greenlight directly need a separate path. | Whether the LMS account is the identity of record, which LMS roles map to moderators, and who owns LMS tool settings. |
| Accounts across paths | Mixed user groups, such as staff through Keycloak and students through the LMS. | The same person may get separate Greenlight accounts, which can split room ownership and recordings. | The unique identifier used to match people, and whether duplicate accounts are merged or kept. |
How Keycloak brokers SAML, Microsoft and Google logins for Greenlight
Keycloak sits between Greenlight and your identity providers, so Greenlight only ever talks to one OpenID Connect client. Greenlight v3 is configured with environment variables to use OpenID Connect, and the Greenlight documentation suggests Keycloak as the way to add Google, Microsoft, SAML and other login methods. In practice, Keycloak acts as an identity broker: users choose an upstream provider on the Keycloak login page, Keycloak authenticates them there, and then Keycloak issues its own token to Greenlight. Greenlight never sees the SAML assertion or the Microsoft or Google token. This keeps the Greenlight configuration stable when you add or retire a provider.
At the conceptual level, you will plan one realm for the BigBlueButton services, one confidential OpenID Connect client for Greenlight with redirect URIs that exactly match your Greenlight hostname, and one identity provider entry per upstream source. Each upstream entry needs its own trust settings: SAML metadata and signing certificates for the SAML source, and application registrations for Microsoft and Google. Confirm the current Keycloak administration steps, the broker types it supports in your release, and the client authentication options against the Keycloak documentation for the exact version you deploy. Those screens and settings change between releases, so do not rely on a runbook written for an older one.
Attribute and claim mapping is where most access decisions are made. Map the email and display name from each upstream provider into the same Keycloak user attributes that Greenlight reads. Choose one stable unique identifier, such as a subject or employee number, and make it the key Keycloak uses to recognize a returning user. Do not use email as the identifier if addresses can change. Group or role claims are the basis for deciding who may host meetings, so decide which upstream groups map to a Keycloak role, confirm that the SAML or Microsoft group claim is actually emitted for your users, and test that a user outside the group cannot create a room. Google typically does not supply group membership, so plan a different rule for those accounts.
Some people will exist in more than one upstream provider, for example a staff member who signs in with both Microsoft and a personal Google account. Decide in advance whether Keycloak should link these identities automatically, only when the email address is verified by both sides, or require the user to link accounts manually after signing in. Automatic linking on email alone can let an account be taken over if an address is reassigned, so most teams prefer verified or manual linking. Also decide what happens to a Greenlight room owned by an account that is later merged or removed.
When an upstream provider is down, Keycloak cannot authenticate users who depend on it, but users of other providers and existing Greenlight sessions are not automatically affected. Test this on purpose: disable one upstream in a staging realm and confirm the login page still offers the others and that the error users see is clear. Keycloak should run on its own patched host or container, separate from the BigBlueButton media servers, with its own database backups and a tested restore procedure. A recovery plan that keeps a local administrator path open is essential, because a broken SAML certificate or expired client secret can lock every user out at once.
Configuring BigBlueButton SSO with Greenlight v3 step by step
This sequence takes a clean BigBlueButton 4.0 server with Greenlight to working single sign-on through Keycloak. Each step closes with a check, so the team can confirm sign-in, role mapping, secret handling, LMS launches and rollback before users depend on the setup.
Install BigBlueButton 4.0 with Greenlight
The administrator starts from a clean Ubuntu 24.04 64-bit server, because BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0. Run bbb-install.sh with the Greenlight option, then confirm that TCP ports 80 and 443 and UDP ports 16384 to 32768 are reachable and that a valid hostname resolves so SSL can be issued. The step is done when the Greenlight front end loads over HTTPS and a test meeting can be joined from a second network.
Deploy Keycloak behind TLS
Install Keycloak on a host or container with its own TLS certificate and a hostname separate from the BigBlueButton server. Create a realm for conferencing users, then add an OpenID Connect client for Greenlight with the redirect URI from the Greenlight v3 external authentication documentation. Store the client secret in your secrets manager, not in a shared document. The check is that the realm's OpenID discovery document loads over HTTPS and a test token request from the client succeeds.
Connect upstream identity providers to Keycloak
Add SAML, Microsoft or Google as identity providers in Keycloak, and map their attributes such as email, name and group membership into the tokens Keycloak issues. Ask each identity provider's administrator which attributes they release, since a missing email claim is a likely cause of failed sign-ins. The check is that a user from each provider signs in through Keycloak and the token shows the expected email and group values.
Set Greenlight v3 OpenID Connect variables
Set the OpenID Connect environment variables described in the Greenlight v3 external authentication documentation, pointing to the Keycloak realm's issuer, the client ID and the client secret. Restart Greenlight and restrict read access to the variable file to the service account and administrators. The check is that the Greenlight sign-in page redirects to Keycloak, and that a local test account lands on the Greenlight dashboard after authenticating.
Map claims to Greenlight roles and protect the secret
Decide which Keycloak groups or claims grant moderator and administrator access in Greenlight, and set that mapping in the realm so group membership drives role assignment. Confirm that the BigBlueButton API shared secret exists only in the server-side configuration, and search the page source, browser network responses and client scripts to verify it is absent. The check is that a test user in the moderator group can start a meeting, while a user outside the group cannot.
Test sign-in and log failed attempts
Sign in first with the local test account, then with each upstream identity provider. Deliberately trigger failures, including a wrong client secret, an expired session and a user missing a required claim, and confirm each one is logged with a reason an administrator can read in the Greenlight and Keycloak logs. The check is that a meeting created from a Greenlight login succeeds and every test failure produces a log entry that identifies its cause.
Run LMS launch tests and document rollback
For Moodle or Canvas users, launch a meeting from a test course and confirm with the LMS administrator how that launch authenticates the user and passes their role. Then write the rollback path: keep a saved copy of the previous authentication settings, define how to disable the Keycloak client, and prepare a notice telling users which sign-in method to use. The check is that the rollback was rehearsed on a test server and that users can still sign in afterwards.
What drives the effort of a BigBlueButton SSO project
This table lists the factors that change how much work a BigBlueButton SSO project takes, why each one matters, and how to keep it manageable. Read it before asking for a quote, because the same Greenlight and Keycloak design can take very different amounts of time depending on these inputs. Because the software is open source, most of the cost is people's time rather than licenses.
| Driver | Why it changes the work | How to keep it down |
|---|---|---|
| Number of identity providers to broker | Each SAML, Microsoft, Google or other provider in Keycloak needs its own configuration, metadata exchange, testing and failure handling. | Limit the first release to the providers users actually need, and add others in a later phase. |
| Identity owner's test tenant and accounts | If the identity team cannot quickly supply a test tenant, test users and a contact for sign-in issues, testing stalls and defects surface late. | Agree on a test tenant, named test accounts and an escalation contact in the written scope before work starts. |
| Claim and group mapping complexity | Mapping email, name, role and group claims to Greenlight roles and to moderator or room permissions needs decisions and repeated testing for each user type. | Document the required claims and the role rules in one table, and confirm them with the identity owner before configuration. |
| LMS changes or configuration only | Moodle or Canvas users who sign in through the LMS need the LTI or integration settings confirmed, while changes to LMS code or themes add development and regression testing. | Confirm the LMS version and whether the existing integration needs only settings changes, and keep code changes out of the initial scope. |
| Number of environments | Test, staging and production each need their own Keycloak realm or client, Greenlight configuration and secrets, and each must be verified separately. | Use one repeatable configuration method for all environments, and state in the quote how many environments are included. |
| TLS and DNS lead time | Greenlight and Keycloak need valid hostnames and certificates, and certificate or DNS changes often depend on teams outside the project. | Request the hostnames and certificate arrangements early, and confirm who controls DNS and certificate issuance. |
| Documentation and handover expectations | Operators need runbooks for adding providers, rotating client secrets and troubleshooting sign-in, and the amount of written material changes the final days of work. | List the required documents, owners and formats in the written scope, and agree on a handover session. |
| Compliance evidence needs, such as access reviews | Assessors may ask for evidence of who can sign in, how roles were assigned and how access is reviewed, which requires logs, exports and a review procedure. | Ask the compliance lead to state the evidence required before design, and check whether Keycloak logs and exports meet it. |
How single node, Scalelite pools and air-gapped sites change the SSO setup
On a single BigBlueButton server with Greenlight installed on the same host, the SSO endpoints share one public hostname and one certificate. The bbb-install.sh script can place the Greenlight front end on the same server as BigBlueButton, so the browser-facing login path, the Greenlight callback and the BigBlueButton API all sit behind one name. This keeps the set of moving parts small, but every change to the hostname affects all three at once.
What changes in each area:
- DNS: One A record serves the Greenlight site. Confirm that the record resolves to the same server that holds the TLS certificate, and that no second name is required for the identity provider unless Keycloak runs elsewhere.
- TLS certificates: One valid certificate covers the public hostname. BigBlueButton needs a valid hostname for SSL, so the certificate must match the name users type.
- Redirect URIs: Register a single callback URL in Keycloak for the Greenlight hostname. Check that the scheme, host and path match exactly.
- Token trust: Greenlight validates tokens from the Keycloak realm you configure. Confirm the issuer URL, the client ID and the client secret, and confirm the signing keys are reachable from the server.
- Logging: Greenlight and Keycloak logs sit on the same host, so one log review covers both. Confirm where each service writes logs and who can read them.
Before the build, confirm the target host has enough capacity for Greenlight alongside BigBlueButton, and confirm the Keycloak instance will not compete with media processing for resources.
When a pool of BigBlueButton servers sits behind Scalelite, Scalelite presents one address to users and sends each meeting to the least loaded server. Greenlight and Keycloak are shared services for the whole pool. The redirect URIs, issuer and certificate must be identical from the browser's point of view, while the PostgreSQL database, Redis cache and the NFS volume that holds recordings keep their own roles and are not part of the SSO path.
What changes in each area:
- DNS: Greenlight and Scalelite endpoints must resolve consistently across the pool. Confirm that no individual BigBlueButton server name is exposed to users as a login target.
- TLS certificates: Plan one certificate for the shared public names and confirm how it reaches each component that terminates TLS, including any load balancer in front of Scalelite.
- Redirect URIs: Register only the Greenlight callback in Keycloak, not one per backend server. A per-server redirect would break when a meeting moves.
- Token trust: Confirm that every component that validates tokens trusts the same issuer and signing keys. Key rotation must be coordinated across the pool.
- Logging: Collect Greenlight, Keycloak and Scalelite logs centrally, since a single login can touch several hosts. Confirm that user identifiers in logs meet your privacy rules.
The shared NFS recording volume and the PostgreSQL database do not carry SSO tokens in the normal flow, so their configuration is largely unchanged by the identity work. Confirm that with the implementer, and confirm that recording access rules still apply after users sign in through the new identity path.
In an air-gapped or on-premises network, Keycloak and the upstream directory, such as Active Directory or an LDAP service, must be reachable from inside the network. Browsers, Greenlight and Keycloak cannot depend on public identity services, public DNS or internet-hosted certificate checks, so every trust relationship must resolve internally. Plan these items before the build, since they often cause the longest delays.
What changes in each area:
- DNS: Internal DNS must resolve the Greenlight and Keycloak names for every client network. Confirm that split-horizon DNS, if used, returns the same names to both internal and external users.
- TLS certificates: Certificates come from an internal certificate authority. Confirm that every client, including Greenlight and Keycloak, trusts that authority, and plan the renewal process.
- Redirect URIs: Register internal hostnames only. Confirm the exact callback URLs with the identity team, since mismatches are the most common login error.
- Token trust: Confirm that Keycloak can reach the directory over the network path you have approved, and that the directory's certificate chain is trusted by Keycloak.
- Logging: Logs may need to stay inside the network. Confirm where they are stored, how long they are kept and whether any forwarding to an external system is permitted.
Before you commit to a plan, confirm with your security and network teams which ports and paths are approved between Keycloak, the directory and the BigBlueButton hosts. Confirm also who holds the certificate authority keys and the Keycloak administrator role.
Why LMS sign-in is a different job for Moodle and Canvas users
For many learners, the Greenlight sign-in flow described elsewhere on this page never happens. BigBlueButton is embedded in learning management systems such as Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology, and in that setup the LMS is the place where people authenticate. A student opens a course, selects the meeting, and the LMS launches the session. Before you add OpenID Connect or Keycloak, decide whether Greenlight is a front end for every user or only for staff and guests who do not have an LMS account. Most institutions find they need both paths, and the LMS path usually carries the larger share of users. In an LMS launch, the LMS has already authenticated the person and passes a signed request to BigBlueButton that identifies the user, the course context and a role. The BigBlueButton side does not need a second password prompt, but it does need the integration configured correctly. Check how the LMS connects to your server: whether it uses LTI or the LMS's own BigBlueButton plugin, which version of each is in use, and where the shared secret is stored. The secret must stay on the server and in the LMS configuration only. Never place it in a template, a course page or a browser-side script, because anyone who reads it can create or join meetings with valid checksums. Running two identity paths for the same person creates predictable problems. A teacher who joins once from Canvas and once from Greenlight may end up with two rooms, two recording libraries and two sets of settings. If the two paths map roles differently, a user can be a moderator in one place and a viewer in another, which affects who can mute participants, start recordings or end the session. Pick one system of record for roles. In most setups that is the LMS enrollment, and Greenlight roles should be derived from the same directory group or claim, not set by hand. To keep moderator and student roles consistent, write down the mapping before testing. List each LMS role (instructor, teaching assistant, student, observer) and the BigBlueButton role it produces, then do the same for each Greenlight group that grants access. Test with one account per role in each path, and confirm that a teacher who starts a room in Canvas sees the same room, moderator controls and recordings when opened from Greenlight. Repeat these checks after every LMS or BigBlueButton update. Before you design any of this, confirm the LMS version and integration method with your LMS administrator and check the current BigBlueButton integration documentation, since plugin behavior and supported LMS versions change between releases. Ask the administrator who owns the shared secret, how it is rotated, and whether the LMS sends a role to BigBlueButton on every launch or only on first join. The answers determine the amount of integration work and the test cases your team will need.
Securing the BigBlueButton SSO path: secrets, redirects and sessions
These controls protect the path a sign-in takes from the browser through Greenlight and Keycloak to the BigBlueButton API. Most weaknesses sit at the seams between these components, so each card names one control and what to check. Firewall rules and host patching are covered in the BigBlueButton security hardening topic and are only referenced here.
Keep the API secret server-side
The BigBlueButton API shared secret signs every API call through a checksum, so anyone who holds it can create or join meetings. Keep it out of web pages, JavaScript bundles and Greenlight front-end code, and compute checksums only in server-side code. The BigBlueButton API docs make SHA-256 the default and list SHA-384 and SHA-512 as available since version 2.5. Use the stronger options where your server version supports them, and limit SHA-1 to legacy clients you cannot yet change.
Exact redirect URI allowlist
Each OpenID Connect client in Keycloak should list the exact callback URLs Greenlight uses, including the scheme, full hostname and path. Wildcards and broad patterns can let an attacker who controls a related subdomain or path receive authorization codes. Recheck the registered URIs after every hostname change, and review the post-logout redirect list separately. Test with a mismatched hostname to confirm Keycloak rejects it.
Client secrets in protected storage
The Greenlight OpenID Connect client secret lets the application exchange authorization codes for tokens, so store it in a secrets manager or in a protected environment file readable only by the service account. Keep it out of version control, container images and deployment tickets. Plan rotation in advance: confirm who can change the value in Keycloak, update the Greenlight environment variables, and restart the service in one change window.
TLS on Keycloak and Greenlight
Browsers reach Greenlight and Keycloak over HTTPS, and the token exchange between Greenlight and Keycloak should also use TLS with certificate validation enabled. BigBlueButton requires a valid hostname for SSL, so issue certificates for the names users actually see. Disable plaintext listeners on the SSO path, and confirm that the issuer URL in Greenlight matches the public HTTPS address of Keycloak exactly.
Session and token lifetimes
Set Keycloak access token, refresh token and SSO session lifetimes on purpose, based on how long a shared lab computer or classroom browser stays signed in. Shorter access tokens limit exposure, while idle session limits suit shared devices. Confirm how Greenlight behaves when a token expires during a session and whether users must sign in again to join a meeting. Record the chosen values so auditors and administrators can trace them later.
Admin console access and failure logging
Limit the Keycloak administration console to management networks or a VPN, and keep it off the public listener used by students and staff. Log failed sign-ins with the timestamp, client, source address and error code, but never the submitted password or token values. Forward these logs to your central log store, and confirm who reviews them and how often.
How to test BigBlueButton SSO and confirm it fails safely
Start by treating the SSO test plan as a set of pass or fail checks that you can repeat after every change to Greenlight, Keycloak, the identity providers or the LMS connection. The first goal is the happy path: each identity provider you have configured, whether that is a SAML source, Microsoft or Google brokered through Keycloak, or a local Keycloak user, should sign in and land in a Greenlight room without manual steps. Run this with a test account from each provider, record the Keycloak realm and client used, and confirm the user is created or matched in Greenlight as expected. Repeat the sign-in in a private browser session so cached sessions do not hide a broken flow. Next, test role mapping with at least one moderator account and one student account from the same identity provider. The moderator should be able to start and manage a room, while the student should join as a viewer without moderator controls. Check the claims Keycloak sends in the OpenID Connect token, because Greenlight decides permissions from what arrives, not from what you intended to send. A mapping that works for one group but silently grants a default role to everyone is a common failure, so include a user who belongs to no group and confirm the role they receive is the least privileged one. The revocation tests matter most for a regulated environment. Disable a test account in the upstream directory, then confirm it cannot start a new Greenlight session. Record how long it takes for access to end, because Keycloak sessions, token lifetimes and Greenlight's own session handling can each keep access alive for a period. Ask your team to set the timing limit they will accept and confirm it in your own environment rather than assuming a default. Also test expired and revoked accounts for LMS-launched users in the same way. Finally, test the failure paths. Deliberately use a wrong redirect URI and then a wrong client secret, and confirm sign-in fails without redirecting to an unexpected host and without exposing tokens in the URL or logs. Stop Keycloak and confirm users see a clear error page, while local administrator access to Greenlight still works. Include LMS launch tests for Moodle or Canvas users, and check that the BigBlueButton shared secret never appears in browser traffic or page source, and that TLS certificates are valid on every hostname involved. Keep the results as a dated test record with the test case, the expected result, the observed result, the software versions and the tester. This record supports handover and can be shared with a compliance assessor. DeployOpen prepares the evidence and the controls, but it does not issue audit results, attestations or certifications. Independent auditors and certification bodies make those determinations.
What do buyers ask before they hire help for BigBlueButton SSO?
Can our in-house team set up BigBlueButton SSO without a partner?
Yes, if your team already runs Linux servers, can administer an identity provider and has time to test logins end to end. The work combines three areas: a BigBlueButton 4.0 server on Ubuntu 24.04, Greenlight v3 configured for OpenID Connect through environment variables, and an identity layer such as Keycloak that brokers Google, Microsoft or SAML logins. Each area has its own failure modes, and the hardest part is often coordination with the people who own the identity provider and the LMS. Ask yourself whether you can staff those skills and keep the work on schedule. A partner is useful when those skills are thin, when the timeline is fixed, or when you want a written scope and handover before go-live.
What makes BigBlueButton SSO cost more or less?
Cost follows the number of moving parts. The main drivers are the identity providers you must connect (one provider is simpler than Google, Microsoft and a SAML source together), the number of environments (test, staging and production each need configuration and checks), the LMS work for Moodle or Canvas users, and the depth of testing and handover. One-time costs include design, build, testing and documentation. Recurring costs include server hosting, patching, certificate renewal and periodic review of role mappings. Ask any provider for a quote that lists each identity source, each environment, each LMS integration, the test cases covered and whether training and runbooks are included. Any figure without that breakdown is hard to compare.
How long does a BigBlueButton SSO project usually take?
Duration depends on scope and on how quickly other parties respond, so no general figure is safe to quote here. The main factors are how many identity providers must be connected, whether a clean BigBlueButton 4.0 server must be built first, how fast your identity owners can grant access and test accounts, how many LMS integrations need checking, and how many environments must be validated before production. Delays often come from waiting on DNS changes, TLS certificates or LMS administrator time rather than from the configuration itself. Ask for a timeline in the written scope that names the dependencies, the people who must act and the dates each one is needed.
What do we need to provide before SSO work starts?
Prepare these items before the first working session. Identity owner access, meaning administrative rights or a named contact on the identity provider, is needed to register the client and map groups or roles. Test accounts for each login method help verify that users reach the right Greenlight role. You need control of DNS and TLS, because BigBlueButton requires a valid hostname for SSL, and the certificate must be issued for that name. LMS administrator time is needed for Moodle or Canvas checks. Finally, the server should be clean, because a 4.0 install is recommended from a fresh Ubuntu 24.04 build and direct upgrades from 2.6, 2.7 or 3.0 are not supported. Confirm each item in the written scope.
Can we add SSO to a BigBlueButton server already in use?
It depends on the version and the state of the server, so confirm both before planning. BigBlueButton 4.0 does not support direct in-place upgrades from 2.6, 2.7 or 3.0, and the project recommends a clean server installation. If your current server is on one of those branches, the practical route is usually a new 4.0 server with SSO built in and meetings or recordings moved across. If you already run a supported setup, ask whether Greenlight v3 is in use and whether its external authentication settings can be changed without disrupting classes. Plan a maintenance window, test a copy of the configuration first and keep a rollback path for the existing login method.
Does the BigBlueButton 4.0 upgrade change the SSO setup?
Yes, it usually changes how you plan the work. BigBlueButton 4.0.0 was released on October 14, 2026, and the project recommends a clean server installation rather than a direct upgrade from earlier branches. For SSO, that means the identity configuration should be built on the new server from the start, and any existing Greenlight settings need to be reviewed rather than copied blindly. The 3.0 branch continues to receive maintenance releases, so teams on that branch may plan the move on their own timeline. Confirm the Greenlight, Keycloak and LMS versions you will run against 4.0 before fixing a scope, and retest every login path after the new server is in production.
What needs patching and renewing after SSO goes live?
Several items need a named owner and a schedule. Keycloak needs security and maintenance updates, because it sits between your users and Greenlight and holds the login configuration. TLS certificates must be renewed before expiry for the BigBlueButton hostname, or users will see errors and be unable to join. Role mappings should be reviewed on a regular basis so that leavers, transfers and new staff receive the right Greenlight access. BigBlueButton server packages, the Ubuntu host and any LMS integration also need updates, and each change should be followed by a test of SSO logins from Moodle or Canvas where those are used. Ask any provider whether these tasks are in a retainer or handover runbook and who responds when a login fails.
Do Moodle or Canvas users need SSO through Keycloak too?
Not necessarily. Users who sign in to BigBlueButton through an LMS can often rely on the LMS sign-in, because the meeting is launched from inside the course and the LMS already authenticates the learner. The LMS integration then determines who may join and in which role. Keycloak and Greenlight SSO matter most for people who sign in directly to Greenlight, such as staff who create rooms or users who arrive without an LMS session. Decide early which audiences use which path, because each path has its own configuration, test cases and owner. Confirm the LMS integration method and its version with your LMS administrator before the design is final.
How DeployOpen scopes, builds and hands over BigBlueButton SSO
DeployOpen plans, implements and documents BigBlueButton SSO with Greenlight and Keycloak inside your own infrastructure, so sign-in decisions stay under your control. Work starts from a written, fixed scope that names the identity sources, Greenlight configuration and LMS integrations in play. The result is a tested setup your team can operate after handover, with support available as a retainer.
How we scope
- The written scope lists which login sources Greenlight must accept, such as SAML, Microsoft or Google.
- We confirm which users sign in directly and which arrive through Moodle or Canvas launches.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- Keycloak realm, clients and identity brokering configured to match Greenlight's OpenID Connect settings.
- Greenlight v3 environment variables set on a clean BigBlueButton 4.0 server running Ubuntu 24.04.
- Client secrets and BigBlueButton shared secrets kept server-side, never embedded in a web page.
How we hand over
- Test sign-in with each login path, including failed logins, expired sessions and a new user.
- Documentation covers the Keycloak configuration, environment variables, firewall ports and recovery steps.
- Your team receives a runbook for rotating secrets and certificates, and adding a new identity provider.
How we support
- Ongoing support and upgrades are available as a retainer, scoped in writing like the original build.
- Re-test sign-in after BigBlueButton point releases, Greenlight changes and identity provider updates.
- Agree in the quote which BigBlueButton branch, 3.0 or 4.0, each server will run.
