Welcome to Week 7, part B #1
Note: This is part 1 of a 3 part series about assignment 7B in the course. This particular assignment was quite information-dense, and if you are unfamiliar with some of the pieces involved, things can be a bit confusing.
In the previous week, we added some security to the system with Transport Layer Security (TLS). This encrypts the web, websockets, and MQTT communications. It also allows clients to authenticate that the servers are who they say they are, and Lampi Devices to authenticate the MQTT bridge connection to the EC2 MQTT Broker. This week we will be focusing on a few remaining security gaps in the model, including:
- protecting the Cloud MQTT broker namespace
- limiting which devices Django users can communicate with at the MQTT level
- providing limitations on Lampi devices specifying how and which topics are mapped into the global MQTT topic namespace on EC2 (and a compromised device could potentially wreak havoc on the entire system)
- requiring authentication of users connecting to the MQTT websockets interface
Where do we begin?
There are a few different ways to skin this security cat. We decided that integrating Mosquitto with Django would provide us with a way to have a single source of truth for Human User authentication, Human User authorization, and Device User authorization. Mosquitto is already configured to authenticate the LAMPIs via the TLS certificates we configured in the previous post. Also, we thought that a REST interface would be easiest to implement for the integration. While we used Django, really any system that supports REST would work with the architecture we’re outlining today.
What does this look like overall?
There are a few moving parts to this solution we decided to go with. Let’s take a look at it overall:
You’ll notice there will be a plugin to Mosquitto that we’ll leverage to connect the Django web app with the MQTT system.
Next post will delve into the ACL support for LAMPI and the Human Users of the system. Stay tuned!