July 12th Update: After this blog post, the folks at Elsevier reached out to me. It appears that they have worked to address this issue. I recommend you read the comment from Jeff Keating, the SVP of Engineering at Elsevier at the bottom of this post. – Bb Guru
Elsevier recently decided to shut down its current LMS. Now instructors and LMS system administrators must address content integrations between learning management systems and the company’s Evolve service. Blackboard Learn environments integrate with Evolve using an LTI/SOAP integration. Blackboard admins deal with these requests from publishers on a regular basis. However, this specific integration creates concerns for them and shows the company’s young experience with Blackboard Learn and this type of integration.
The main reason for concern comes from Elsevier requested entitlements for its integration. But what do these entitlements do? I sought to find some additional information on the topic. If you have ever installed a building block in Blackboard, you will see a page similar to the one below. The entitlements are the LTI/SOAP integrations version of these privileges in building blocks. They require this access to control the integration’s abilities which run outside of the Blackboard Learn environment.
So these entitlements make sense for Elsevier Evolve. So let’s look at a sample of the entitlements they want of a Blackboard instance.
system.admin.VIEW : Required to get classifications and manage cartridges. system.announcements.CREATE : Required to create system Announcements. system.announcements.DELETE : Required to delete system Announcements. system.announcements.MODIFY : Required to modify system Announcements. system.announcements.VIEW : Required to view system Announcements. system.calendar-item.EXECUTE : Required to create, modify, or delete system Calendar Entries. system.calendar.VIEW : Required to view system Calendar Entries. system.course-categories.VIEW : Required to view course or organization categories. system.course.CREATE : Required to create courses. system.course.DELETE : Required to delete courses. system.course.VIEW : Required to view Courses or Course Category Memberships. system.course.categories.MODIFY : Required to save, change, or delete course categories. system.org.properties.MODIFY : Required to change organization properties through changeOrg___, updateOrg, or saveCourse methods. system.term.MODIFY : Required to create, update, or delete Terms system.term.VIEW : Required to view Term information system.user-institution-role.MODIFY : Required to save users. system.user-password.MODIFY : Required to save users. system.user-system-role.MODIFY : Required to save users.
As you can see, I’ve highlighted several of these listed that concern many administrators. I know of no administrator who would give a publisher the ability to create, modify, and delete announcements from Blackboard. Nor would a Blackboard administrator allow a publisher to create and delete courses from the Blackboard Learn administrator! Finally, the biggest issue we found was the ability to modify the system role of users so Elsevier could technically make a student user a system admin role with this entitlement.
These are just nine of twenty-three entitlements requests flagged by our team, about a third of the total entitlement requests by the publisher. We weren’t the only institution concerned with these requests. In April, a discussion thread on the Blackboard Community site started with various Blackboard administrators discussing the issue.
When faced with these kinds of requests, an administrator should evaluate the integration or application in the same way institution applications are reviewed. If the vendor requests modify permissions, request that they provide a reason for this permission. If they can’t provide a satisfactory one, you may do any of the following: reject the permission request, only allow a READ permission, or reject the permission entirely. If you have a test or staging environment, implement the integration there and test it thoroughly to make sure any and all concerns are addressed. In the end, it’s the institution’s job to protect the data of users and ensure any campus application has zero chance of being compromised.
At the beginning of May 2018, we submitted our concerns to Elsevier and stated we could not enable the integration until these issues were addressed. As of June 2018, Elsevier has not responded to our concerns. However, Blackboard system admins from other institutions have expressed their concerns about these broad entitlement requirements to Elsevier support and were told that this was the first time they had heard of such concerns.
Technically Yours,
The Blackboard Guru
First, our apologies for taking so long to respond. We have traced back what happened.
When developing a solution to interact with a SOAP API like the Blackboard API, a common path is to enable everything at first. That way one can build a solution with full access to the API, without any concern over permissions. The principle, however, is to use the minimum necessary access. In this case, we didn’t close the loop with our communications and a few customers notified us that we had requested too many services. Given that the solution only leveraged a small subset, we notified those customers and have updated our documentation and communication – our “Grade Sync” feature never used more than three services.
We will continue to refine this going forward. Thank you for bringing this to our attention.
Reading Jeff’s reply really makes me question the version designation for the software product released by Elsevier, not just for the Blackboard environment but also for the Brightspace environment.
It really sounds like an Alpha release and didn’t even make it to Beta.