Identity architecture
SSO with Microsoft Entra ID, Google Workspace and LDAP
Greenlight speaks OpenID Connect. Entra ID and Google can provide OIDC directly; LDAP usually enters through an identity broker such as Keycloak. The design work is in claims, lifecycle and recovery—not the login button.
Executive brief
What matters
- 01
Greenlight v3 supports OIDC; use exact HTTPS redirect URIs and protect the client secret.
- 02
Use Keycloak or another broker when LDAP, multiple providers or central claim mapping is required.
- 03
Keep a tested emergency administrator path and define deprovisioning before enabling just-in-time accounts.
01
Choose direct OIDC or a broker
A single Entra ID or Google Workspace tenant can connect directly if its claims match your needs. Keycloak becomes valuable for LDAP/Active Directory, several identity sources, central MFA policy or stable claims across providers. Each extra layer is also another certificate, database and upgrade responsibility.
02
Register the client precisely
Create a confidential web client, use the Greenlight callback URL exactly as documented and permit only HTTPS production origins. Store issuer, client ID and client secret in protected environment configuration. Microsoft and Google both require redirect URIs to match registered values; loose wildcard habits create security and support problems.
03
Map identity deliberately
Choose a durable unique identifier, then map display name and email. Do not use a mutable email address as your only account key without understanding rename and collision behaviour. Decide which groups may sign in and how application roles are assigned. LDAP sync modes and group mappings should be tested with nested groups and disabled accounts.
04
Test lifecycle and failure
Exercise first login, returning login, email change, account disablement, group removal and provider outage. Limit local-password registration if SSO is authoritative, but retain a controlled break-glass route. Rotate the client secret in a rehearsal and ensure logs reveal configuration errors without recording tokens or personal claims.
Evidence base
Sources and further reading
We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.
- Greenlight external authentication docs.bigbluebutton.org ↗ (opens in a new tab)
- Microsoft identity platform OIDC learn.microsoft.com ↗ (opens in a new tab)
- Google OpenID Connect developers.google.com ↗ (opens in a new tab)
- Keycloak identity brokering and LDAP www.keycloak.org ↗ (opens in a new tab)
Practical answers
Questions teams ask
Can Greenlight connect directly to LDAP?+
Greenlight v3 documents OIDC. A common pattern is to federate LDAP or Active Directory into Keycloak, then expose OIDC to Greenlight.
Should I use email as the unique user ID?+
Prefer the provider’s stable subject identifier where the integration supports it. Email addresses can change or be reassigned.
Can SSO groups make users BigBlueButton moderators?+
The surrounding application controls meeting roles. Treat any group-to-role mapping as privileged authorisation and test it explicitly.
Continue the research
Related guides and infrastructure
Greenlight administration for production
Operate Greenlight safely: identity, roles, rooms, SMTP, database backups, upgrades, recording visibility and support boundaries.
Read next → IntegrationIntegrating with the BigBlueButton API
Build a secure BigBlueButton integration for meeting creation, role-based joins, callbacks and recording management.
Read next → InfrastructureAn isolated server for Greenlight, PostgreSQL and Redis
Deploy Greenlight on its own server for a cleaner BigBlueButton architecture, independent database lifecycle and easier cluster growth.
Read next →