Blackboard Learn provides support for three-legged OAuth 2.0 authorization.
Three-legged OAuth (3LO)
Developers can create applications using REST APIs that act on a user's behalf in a more secure way. When authorized using 3LO, applications can act on behalf of a user and therefore are restricted to the parts of Blackboard Learn for which that user has permissions to access.
Students and instructors must allow integrated applications to access their personal information in Learn. For more information about authorization, see Authorize Access to Integrated Apps.
Register a third-party integration
Blackboard Learn supports the integration of external applications built using Blackboard Learn REST APIs. Before you can use an integration with Blackboard Learn, an administrator must register it.
Before you begin to register the application, you must obtain an application ID. The developer may provide the ID directly to the administrator or bundle it with the support documentation for the application.
- From Administrator Tools, under Integrations, select REST API Integrations.
- On the REST API Integrations page, select Create Integration.
In Application ID, enter the application ID proved by the integration's developers.
The integration's developers should provide the ID. They should never ask you to create an application registration in the Anthology developer portal unless they're creating custom software, just for you. If a vendor of commercial, off-the-shelf software requests this of you, please have them contact us for assistance.
In Learn User, find the user the integration should act as. Typically, you should create one user per application, using a customized role with only the permissions the vendor indicates that the application requires.
Anthology recommends that you never select a user with the system role of “System Administrator” for REST API applications because there will be no limits on the application’s ability to access information. If a vendor requests that you use “System Administrator,” please have them contact us for assistance.
- If the application needs to "act for" an end-user, set End User Access to Yes. Users will be prompted with the third party consent workflow the first time they access this app.
- If you select Yes for End User Access, you can also choose to bypass the consent workflow. To do this set Authorized To Act As User to Yes. You should carefully consider the privacy, legal and other implications of this choice. See the section on Trusted Services below for more information.
- If you set End User Access to No, the integration always has access to Learn as if it were the Blackboard Learn user selected in Learn User. If the selected user has access to user personal data, the integrated application will have access too.
- Select Submit to save your settings for the integration.
Trusted Services
A trusted service will communicate with Blackboard Learn in a very similar way that third-party developed applications communicate with Blackboard Learn. An application for the trusted service must be created in the developer portal, and the trusted service uses those credentials to interact with Learn.
Trusted services can do the following:
- Automatically have a Blackboard Learn site register itself as integrated with that trusted service and not let site admins remove that integration
- Bypass rate limits and site quotas normally placed on application integrations
- Utilize 3 Legged OAuth without having to present the Blackboard Learn end user with an allow/deny integration UI;
A third-party application that isn't a trusted service remains editable and selectable, while the trusted service application can’t be selected. The menu for actions on the trusted service also shows only the View buttons.
Do I need to allow end user access?
The integration application's vendor should be able to tell you if their application requires end user access. A typical example of when access is necessary is an application that creates activity in a course. For example, a discussion board application needs end user access to make postings as the logged in user. Otherwise, discussion board postings would all appear to be from one generic account.
An example of an application that would not require end user access is one that integrates with SIS to create/manage courses, users, or enrollments. In this scenario, the application should have only its own user, and that user should have a role granted only the permissions needed. The app doesn’t need to “act for” a specific user to achieve its functionality.
