Connect Brightspace (D2L)

This guide is for Brightspace (D2L) administrators connecting their institution to Alexandria. It assumes you know your way around the Brightspace admin interface, but not that you work with LTI every day, so it spells out the parts that commonly cause confusion.

Setup takes about five minutes.

Before you start: three things Brightspace keeps separate

The single most common reason an LTI setup “doesn’t work” is that one of these three steps was completed and the other two were not. They live on different pages, and finishing the first gives no indication that the others are outstanding.

Object	What it is	Where it lives
Registration	The trust relationship: our URLs, our keys, your issuer	Admin Tools → Manage Extensibility → LTI Advantage
Deployment	Which org units the tool is switched on for	Admin Tools → External Learning Tools → LTI Advantage
Link	The thing an educator or student actually clicks	Created from the deployment, or by an educator in the course

Register the tool and you have told Brightspace that Alexandria exists. You have not yet made it available in any course. That takes the deployment, then a link.

LTI is not the same as an API key

The LTI registration below handles launching and identity, and it is all Brightspace needs. Alexandria does not require a separate Brightspace OAuth 2.0 API key for the LTI integration to work.

If you later want automated course and roster sync through the Valence API, that is a separate credential and a separate conversation. Do not create one now.

Step 1: Register the tool

Alexandria supports Dynamic Registration: you paste one URL, and Brightspace and Alexandria negotiate every endpoint, key, and claim between themselves. There is nothing to type by hand and nothing to copy back and forth.

1. Go to Admin Tools → Manage Extensibility → LTI Advantage.

2. Click Register Tool.

3. Choose Dynamic, not Standard.

4. In Tool initiation registration endpoint, paste:

   https://production-backend.libraryofalexandria.nl/lti/register

5. Leave Configure Deployment ticked. It is ticked by default. Step 2 explains what to check afterwards, because a deployment needs several settings that only you can choose.

6. Click Register.

Enlarge

Dynamic registration needs one URL and nothing else.

Brightspace contacts Alexandria, and Alexandria registers itself. When it finishes you will see the tool listed as Library of Alexandria, with the domain, redirect URL, OpenID Connect login URL, and keyset URL already filled in, plus a client ID that Brightspace generated.

You do not need to enable any Extensions. Assignment and Grade Services, Names and Role Provisioning, and Platform Notification Service all stay off. Alexandria does not use them, and enabling them grants access we neither need nor want.

What Alexandria receives

The registration requests three claims only: the issuer, a stable user identifier, and the user’s email address. Brightspace also sends the course context and the user’s role with each launch. Nothing else is requested.

Requesting the email claim is not the same as being given it. Brightspace decides that separately, per deployment, under Security Settings. Step 2 covers it.

Step 2: Create or check the deployment

A registration tells Brightspace that Alexandria exists. A deployment is what makes it usable, and it is where every setting that matters to your institution lives: which courses the tool covers, and what Brightspace is allowed to tell it about the person launching.

1. Go to Admin Tools → External Learning Tools → LTI Advantage.

2. Look for a deployment whose Registration Name is Library of Alexandria. The list opens on the Enabled filter, so switch to All before concluding that nothing is there.

3. If a deployment exists, open it. If none does, click New Deployment, then on the Deploy Tool page choose Library of Alexandria under Tool and give the deployment a Name you will recognise later, such as the faculty it serves.

   Enlarge

   A deployment is created against a registration you already have. The tool dropdown lists your registered tools and nothing else.

4. Leave every checkbox under Extensions unticked. Assignment and Grade Services, Names and Role Provisioning Services, Platform Notification Service, and Asset Processor are all off by default and Alexandria uses none of them.

5. Under Security Settings, tick Email. Alexandria identifies people by their email address, and a launch that arrives without one cannot be completed.

   Enlarge

   Email is the only box Alexandria needs. Everything else stays off.

6. Under Configuration Settings, tick Open as External Resource. This is the setting that makes Alexandria open in its own tab.

   Enlarge

7. Switch Auto Migrate Links on. It is off on a new deployment. This is Brightspace’s own mechanism for carrying LTI links across course copies, and turning it on saves educators from rebuilding links every semester.

   Enlarge

8. Set the scope under Make tool available to, as described in the next section.

Nothing under Security Settings is ticked by default

The section is headed Select the information to share with the tool, and on a new deployment every box in it is empty. That is a sensible default, but it means the deployment shares no email address until you tick Email yourself.

An admin who skips this section gets a deployment that looks complete. Launches then fail with a message asking the user to have their administrator include the email claim. If you are reading this because of that message, this is the box.

If the tool loads a blank frame, this is why

Alexandria signs users in through a secure cookie exchange, which browsers only permit in a top-level tab. With Open as External Resource unticked, Brightspace renders Alexandria inside an iframe, third-party cookie restrictions block the sign-in, and the tool appears to hang.

If a user reports “it just spins”, this checkbox is the first thing to check.

What the deployment shares, in full

Security Settings is the complete list of what Brightspace will hand over, and it is worth reading before you approve the integration:

Setting	Alexandria’s use
Email	Required. It is how an account is matched or created.
Name, and First Name / Middle Name / Last Name	Not used. Leave unticked.
User ID, Username, Org Defined Id	Not used. Leave unticked.
Classlist including users not known to this deployment	Not used. Leave unticked.

Independently of these boxes, every LTI launch carries the issuer, the deployment, a stable pseudonymous identifier for the user, the course context, and the user’s role. Those are part of the LTI protocol rather than settings you control here.

Each deployment also has its own Deployment Id, shown under Brightspace Deployment Details, separate from the registration’s client ID. One registration can carry several deployments, for instance one per faculty with different org unit scoping. Alexandria recognises new deployment IDs from a registration it already trusts and accepts them automatically, so you never need to tell us about a new one.

Deciding which org units Alexandria covers

This is the decision an institution actually deliberates over, and Brightspace expresses it entirely through Make tool available to at the bottom of the deployment.

Click Add Org Units. The dialog lists your org units with a Type column and, for anything that can contain other org units, a set of Options:

• This org unit covers the node itself and nothing beneath it.
• All descendants covers everything beneath the node but not the node itself.
• This org unit and all descendants covers both.

A course offering has no options at all, because there is nothing underneath it.

Enlarge

Every row that can contain other org units starts on This org unit.

Every row starts on This org unit

Ticking a department or a semester and clicking Add without touching the radio buttons scopes Alexandria to that node alone. No course inside it is covered, so nobody gains access, and the deployment still reads as configured.

Whenever you pick anything other than a single course offering, choose This org unit and all descendants deliberately before you click Add.

Once added, each choice appears as its own line, and the wording tells you exactly what you selected. This org unit and all descendants produces two lines, one for the node and one for everything under it.

A brand new deployment arrives with The Organization already in the list. Remove it with the cross beside it if you are running anything narrower than an institution-wide rollout. A removed line stays visible with a line through it and a plus to put it back, so you can see what you are about to change before you save.

Enlarge

The Organization line has been removed, a whole department added with its descendants, and one further course offering added on top.

How you combine these depends on the size of the rollout:

• A pilot. Remove The Organization and add only the participating course offerings. Each one is a single line and covers exactly one course.
• A faculty-wide rollout. Remove The Organization and add the faculty’s department or semester with This org unit and all descendants.
• An institution-wide rollout. Add the organisation itself with This org unit and all descendants, so that a second line reading Every Org Unit under The Organization appears next to it. The line a new deployment starts with names the organisation on its own, which is not the same thing.

Enlarge

A pilot scope: one course offering, nothing else.

Brightspace has no notion of an exception that takes access away. The list is additive only, so a course is covered when something in the list covers it, and excluded otherwise. To keep one course out of an otherwise faculty-wide rollout, add the individual courses that should have Alexandria rather than the department, or move the course to an org unit outside the scope.

If you scope a deployment to a single test course now, remember to widen it before going live.

Step 3: Create a link

The deployment makes Alexandria available. A link is what people click.

From the deployment page, use View Links to create one. Educators can also add Alexandria themselves from inside a course, which is worth knowing so that you can answer the question when it is asked: in the course, open Content, choose Add Existing on a module, and pick External Tool Activity.

Enlarge

Inside a course, the dialog lists the LTI link next to the deployment it came from. A course outside the deployment's scope shows nothing here.

That list is the clearest test of your scoping work. If Library of Alexandria does not appear for a course you expected it to cover, the deployment’s org unit scope is the reason, not the link.

At this point the admin work is done.

Step 4: Institution verification

Brightspace instances hosted by D2L sit on a brightspace.com address. That address identifies D2L rather than your institution, so we cannot automatically verify which school a registration belongs to. Registrations from these instances are reviewed by a person before they go live.

During registration Alexandria asks for a contact name and email. Fill it in and we will confirm the connection, typically within one working day. Launches show a holding message until then.

If your Brightspace runs on your institution’s own domain, verification is automatic and the connection is live immediately.

Manual registration

Use this only if your institution’s policy forbids dynamic registration. It is more error-prone and there is no advantage to it otherwise.

In Register Tool, choose Standard, and enter:

Field	Value
Domain	https://production-backend.libraryofalexandria.nl
Redirect URL	https://production-backend.libraryofalexandria.nl/lti/launch
OpenID Connect Login URL	https://production-backend.libraryofalexandria.nl/lti/login
Keyset URL	https://production-backend.libraryofalexandria.nl/lti/jwks

Leave all Extensions unticked. Then email us the client ID, deployment ID, and your issuer so we can complete the connection from our side. A manual registration does not work until you do this: unlike dynamic registration, we have no way of learning those values on our own.

What educators and students see

The first educator to launch Alexandria from a course is taken to a setup page where they link the Brightspace course to Alexandria and choose which materials the AI may use. This takes a few minutes and happens once per course. Every launch after that goes straight into the course.

A student who launches a course the educator has not set up yet sees a page explaining that the course is not ready and asking them to check back. They never see an error, a blank screen, or another course’s content.

Course copies and new semesters

Brightspace assigns a copied course a new context ID. Alexandria reads the course from the launch every time, rather than remembering it against the link, so a copy is treated as a new course: the educator is walked through setup again, and students see the “not ready yet” page until that is done.

Launches never break, and they never silently serve the previous semester’s materials.

Troubleshooting

Brightspace-specific problems are below. For issues common to every LMS, see Troubleshooting LTI launches.

The tool opens a blank frame or spins forever. Open as External Resource is unticked on the deployment. See step 2.

Educators cannot find Alexandria in their course. The registration and deployment exist but no link has been created, or the deployment’s org unit scope does not include their course. See steps 2 and 3.

A newly created faculty cannot launch. Its org unit is outside the deployment’s scope. Add it under Make tool available to.

A whole department was added but none of its courses can launch. The org unit was added with the default This org unit option, which covers the department node alone. Add it again with This org unit and all descendants. See step 2.

Launches report that no email address was sent. Email is unticked under the deployment’s Security Settings. It is unticked on every new deployment. See step 2.

A deployment you created cannot be found in the list. The LTI Advantage list opens on the Enabled filter. Switch to All.

Data and privacy

• Received per launch: issuer, a stable user identifier, email address, LTI role, and course context. Nothing else. The email address is the only one of these that you switch on yourself, under the deployment’s Security Settings, and the rest of that section stays unticked.
• Hosting: processed and stored in the EU on Google Cloud. Encrypted in transit (TLS 1.2 and above) and at rest (AES-256).
• No data resale, no advertising, no behavioural monetisation, as a contractual commitment.

Full detail is in the Trust Center and the privacy policy.