Integrate BigBlueButton with Open edX

01

Choose the supported integration path

The documented generic route is LTI: install the BigBlueButton LTI broker/rooms components, then register its launch URL in Open edX. Confirm whether your release and chosen XBlock expect LTI 1.1 or LTI Advantage—credentials are not interchangeable.

• Open edX/Tutor administrator and Studio access.
• LTI version selected and compatible BBB component confirmed.
• Dedicated key/secret and a disposable course for testing.

02

Prepare BigBlueButton and credentials

Use a production BigBlueButton endpoint with a trusted TLS certificate. Keep the API shared secret or LTI secret on the server side: it is equivalent to an application credential and must never be placed in browser code, a public repository or a screenshot.

1. 1

   Confirm the BigBlueButton server is healthy and that its public hostname resolves correctly.

2. 2

   Retrieve the API URL and shared secret with sudo bbb-conf --secret, or create a dedicated LTI key and secret where the integration uses LTI.

3. 3

   Record the platform version, connector version, owner and rollback point before making the change.

# Install BBB with a dedicated LTI credential using the current official script option:
# -t OPENEDX_KEY:LONG_RANDOM_SECRET

03

Configure Open edX

Make the first connection in a staging course, workspace or tenant. Use a dedicated test teacher and test learner so role mapping can be observed rather than inferred from an administrator account.

1. 1

   Install the current BBB LTI framework using the official bbb-install option for your supported release.

2. 2

   Test the /lti launch URL with the recommended conformance/test tool.

3. 3

   Enable the matching LTI component in Open edX advanced settings.

4. 4

   Add the LTI unit in Studio, enter launch URL and credentials, then publish.

04

Run an end-to-end acceptance test

A green “connection successful” message proves only that one API request worked. The useful test follows the complete classroom lifecycle from creation through recording publication.

1. 1

   Launch as course staff and learner; inspect role claims.

2. 2

   Confirm anonymous or unenrolled access is rejected.

3. 3

   Test mobile web launch, return navigation and third-party-cookie restrictions.

4. 4

   Record and verify how playback is exposed to learners.

05

Common problems and practical fixes

Start with timestamps, browser developer tools and the logs on both sides. Repeatedly replacing secrets rarely fixes a hostname, TLS, role or callback problem and makes the evidence harder to follow.

• A blank iframe can be CSP, X-Frame-Options or cookie policy rather than LTI signing.
• OAuth signature errors frequently come from URL normalization or clock drift.
• Tutor upgrades may overwrite unmanaged settings; store changes in the supported plugin/config layer.

06

Production hardening and upgrades

Restrict who can create rooms, define recording retention, test accessibility and document the integration owner. Pin or approve connector updates, subscribe to upstream releases and repeat the acceptance test after changes to the LMS, connector, BigBlueButton or reverse proxy.

• Do not expose the BigBlueButton shared secret to course authors or client-side JavaScript.
• Use least-privilege teacher roles and test guest, suspended and unenrolled users.
• Monitor API errors, failed joins, recording processing and disk growth.
• Keep a short rollback runbook: previous package, configuration backup and maintenance window.