ATTENTION ADMINISTRATORS! - MLCS just moved! You may need to adjust firewall exceptions.
Blackboard mobile products may require some modifications to your institution's network configuration (firewall/IP whitelist) to permit data to move between Blackboard Learn and Blackboard's mobile products. The Blackboard app utilizes two cloud services: MLCS and mBaaS. Both services are maintained by Blackboard.
MLCS is the Mobile B2 registration service that handles the school search during authentication. mBaaS is a backend service that handles all other data requests between Blackboard Learn and the Blackboard app.
MLCS is now hosted in the Amazon Web Services cloud. Due to the dynamic nature of the scaling features of the AWS cloud, outbound traffic is sent via proxy through a series of static IP NATs to provide a more manageable set of firewall exception points.
The mobile B2 must communicate outbound with the following hostnames:
And the Learn server must accept inbound traffic from the following static IPs:
There is a PTR record for reverse DNS lookup on this IP: cheerful.medu.com
If a firewall exception is made for the "*.medu.com" wildcard domain, this rule will cover all outbound and inbound requirements for Mobile B2 registration.
For mBaaS, the end-user device and client servers must communicate bi-directionally with the following hostnames/IPs:
- Mbaas.bbpd.io (legacy app versions)
- Mbaas.mobile.medu.com (modern app versions)
- Mbaas.blackboard.com.cn (modern app versions for China)
- 188.8.131.52 (North America and South America traffic NAT)
- 184.108.40.206 (Europe and Africa traffic NAT)
- 220.127.116.11 (Asia traffic NAT)
- 18.104.22.168 (South Pacific traffic NAT)
- 22.214.171.124 (Japan traffic NAT)
- 126.96.36.199 (China traffic NAT)
Note that clients in China have two options for whitelisting domains.
These services call outbound to client servers via a static IP NAT, which are listed above. DNS lookups for "mbaas.mobile.medu.com" will not resolve to the NAT IPs listed.
Example: An end user's mobile device sends requests to mbaas.mobile.medu.com, which is routed to the closest of the regional mBaaS AWS deployments. MBaaS then calls to the client server through an outbound NAT with IP per above depending on which regional deployment is being used (i.e. - where in the world the end-user is located).
MBaaS.mobile.medu.com has multiple regional AWS deployments. Depending on how the firewall is configured, administrators may need to open each of the regional NAT IPs to ensure all global traffic is allowed. For example, if the firewall performs regular DNS lookups to refresh the rules, it may only include results for the local DNS. In this case, a U.S. school firewall only sees the DNS query result for mbaas.mobile.medu.com in AWS US-East (188.8.131.52). However, the school has students in Japan, so the server must also allow the Tokyo mBaaS (184.108.40.206), and so on.
The creation and maintenance of Blackboard mobile applications is unique and complex because Blackboard Learn servers are not a single set of SaaS machines hosted by Blackboard. Our mobile applications need to work against a variety of different Blackboard Learn instances, where each instance may be at a different version and patch level. In order to work properly against all of these variations, our mobile applications need to understand all of the features, bugs, and institutional customizations for every production Learn instance. This created a lot of bloat in our previous mobile applications and made support challenging, as Blackboard can neither force an upgrade/patch on an individual institution's Learn instance nor on a student's mobile device.
To alleviate these issues, Blackboard reworked the way our new mobile applications interact with Blackboard Learn instances. Blackboard created a mobile backend as a service (mBaaS) that runs on AWS (Amazon Web Services). mBaaS allows our mobile applications to interact with a single set of servers that can abstract various Blackboard Learn versions, bugs, patches, and so on. If a client upgrades a Blackboard Learn instance that introduces a customization bug, Blackboard can now respond by patching a single service immediately rather than creating a new version of our mobile applications that need to be approved, released, and downloaded from the app stores.
mBaaS is designed to better service our customers, both institutions and students, by reacting to changes quickly from a single code line. mBaaS is not a storage service. While we may cache some information for a small amount of time to create a better user experience, there is no permanent storage on this service. All PII data transmitted and cached through mBaaS is SSL encrypted and in compliance with FERPA and other similar international laws.
mBaaS servers are currently located in the United States, Germany, Singapore, Japan, and Australia. Blackboard uses AWS Route 53 GEO DNS to route client traffic to the closest globally deployed mBaaS. For example, traffic from EU mobile users routes to the EU mBaaS and calls are then made to the local EU Learn instance. Many countries don't want their traffic routed through the United States, and we've implemented this routing to help alleviate those concerns.
Note that the architecture of this mBaaS relay marks a change in Blackboard’s mobile strategy from previous mobile products. The next-generation role-based Blackboard app and Blackboard Instructor app utilize mBaaS. However, the discontinued Bb Grader app and discontinued Mobile Learn app operated differently in the past and previously routed all connections directly to the Blackboard Learn environment.
We are excited to see this technology utilized on our new set of mobile applications, and we look forward to providing a high level of service to our clients and students with our new mBaaS layer.