ATTENTION ADMINISTRATORS! - MLCS just moved! You may need to adjust firewall exceptions! For all the details, please see the support bulletin at: https://blackboard.secure.force.com/btbb_articleview?id=kAA39000000blMr
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. Bb Student 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 Bb Student.
Mobile Learn and Bb Grader use MLCS only.
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
So, 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)
- 220.127.116.11 (North America and South America traffic NAT)
- 18.104.22.168 (Europe and Africa traffic NAT)
- 22.214.171.124 (Asia traffic NAT)
- 126.96.36.199 (South Pacific traffic NAT)
- 188.8.131.52 (Japan traffic NAT)
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 (184.108.40.206). However, the school has students in Japan, so the server must also allow the Tokyo mBaaS (220.127.116.11), 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.
We realize a lot of countries do not want their traffic routed through the United States, and have implemented this routing to help alleviate those concerns. Note that mBaaS is currently only specific to the Bb Student app. The Mobile Learn app operates differently. Mobile Learn routes all connections directly to the Blackboard Learn server the device and application are trying to access.
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.
Email Support (available in English only)
@BbMobileSupport on Twitter (available in English only)