Implementing Security Labels in Matrix
In some environments, governments and regulated organisations can't simply put people in a room and let them talk. What can be shared, and who can read it, is governed by a formal classification policy and by the clearances held by everyone present.
This talk walks through a working implementation of security labelling in Matrix using Synapse, Element Web and Advanced Identity & Access Management. We'll cover how policies are expressed, how labels attach to rooms and messages, and how the server enforces them. We'll then finish with a live demo.
In defence, government and regulated industry, "who is allowed to see this" isn't a matter of room membership - it's a label against the message itself.
Users hold clearances, information carries a classification, and the system should guarantee the two are checked against each other. That expectation is a large part of why many of these organisations are still on older platforms, i.e. XMPP.
- What security classifications are, why they're used and who uses them.
- What are Security Policy Information Files (SPIF) and how are they used to express security classifications.
- A brief look at the proto-MSC written that guided this implementation
- A focused look at the work we did in Element Web to support message labels.
- How we got synapse to enforce these policies, including talking to an authorisation service.
- A live demo that shows all the pieces working together.
Who this is for: anyone building Matrix for a regulated or classified environment, plus spec and client developers curious about how we approached implementing labelling in Matrix generally.
I'm a Software Engineer at Element, where I primarily work on the Element Web team.
Kieran is a Senior Technical Engineer at Element helping customers configure and deploy Element Server Suite (ESS) Pro, having specifically been focused this year on our Mission Partner Environments (MPE) version that supports Security Labelling in Matrix.