EMQX ACL 授权
授权ACL
MQTT 授权（authorization）是指对 MQTT 客户端的发布和订阅操作进行 权限控制。 控制的内容主要是哪些客户端可以发布或者订阅哪些 MQTT 主题。
EMQX 支持集中类型的授权。
- 权限列表（亦即 ACL）。可以从例如 MongoDB， MySQL，PostgreSQL，Redis，或者 EMQX 的内置数据库中读取这个列表。
- 加载一个包含全局的 ACL 的文件。
- 动态访问一个 HTTP 后端服务，并通过该 HTTP 调用的返回值来客户端是否有访问的权限。
- 通过提取认证过程中携带的授权数据，例如 JWT 的某个字段。
个人理解，在智能家居的业务场景中，一个很重要的安全保证是：用户只能控制自己家里的智能设备，比如关灯，而不应该关闭隔壁邻居家的智能灯泡。因此，需要对客户端订阅/发布 关键指令做授权管理。
授权数据源
授权数据源 （或称 Authorizer） 是 EMQX 中实现权限控制的一个模块。 每个控制器都有一个类型，EMQX 内部也把它用作唯一的标识符。
EMQX 默认提供如下这些 Authorizer：
| 类型（ID） | 描述 |
|---|---|
| built_in_database | 使用内置数据库存授权数据 |
| mysql | 使用MySQL存放授权数据 |
| postgresql | 使用PostgreSQL存放授权数据 |
| mongodb | 使用MongoDB存放授权数据 |
| redis | 使用Redis存放授权数据 |
| http | 通过访问外部HTTP服务来获取授权信息 |
| file | 将授权信息存放在文件中 |
EMQX 默认采用文件授权的方式。
在之前的Blog中，有写过EMQX 默认不能订阅系统主题，需要打开开关才行，上图标红的地方。
授权链
一组Authorizer，组成一个授权链。当一个客户端端进行发布订阅时，EMQX会按顺序逐个检查。如果一个 Authorizer 能够找到该客户端的授权规则（ACL），那么就会对这个规则进行匹配。 匹配的结果要么是允许（allow），要么是拒绝（deny）。如果没有找到适用于该客户端的规则， 那么就会继续到授权链中的下一个 Authorizer 进行检查。
简单的理解，授权链类似开发代码时用到的责任链模式，在整个授权链中只需要有一个授权满足，即满足要求，后面的授权规则不进行匹配。
规则占位符
多数 Authorizer 支持在授权规则中使用占位符。 占位符就像是一个模版，在运行时根据客户端信息进行替换，得到真正使用的授权规则。
Authorizer 配置中的占位符
配置中的占位符会在运行时进行替换并使用在后端数据库或服务的链接或者请求中。 下面是 EMQX 支持的占位符：
${clientid}— 客户端的 clientid。${username}— 客户端的用户名（username）。${peerhost}— 客户端的源 IP 地址。${cert_subject}— 客户端 x.509 证书中的主题名（Subject）。${cert_common_name}客户端 x.509 证书中的通用名（Common Name）.
需要注意: 当占位符不存在时，数据会被替换成空字符串，如当客户端没有传递username参数，则：
HMGET users:${username} password_hash salt is_superuser` 会被替换为 `HMGET users: password_hash salt is_superuser
主题占位符
在 Authorizer 后端返回的规则中，MQTT 主题是字符串格式。这些字符串会被当作模版进行占位符的替换。 在授权规则中可以使用的占位符如下：
${clientid}— MQTT 客户端的 Client ID。当在规则中使用 Client ID，这个 ID 应由客户端在连接 EMQX 前就指定，而不是让 EMQX 随机生成。${username}— 使用客户端用户名 对规则进行替换。
占位符只能用于替换主题的整个字段，例如 a/b/${username}/c/d，但是不能用于替换字段的一部分，例如 a/b${username}c/d。
为了避免占位符跟想要的主题冲突的问题，EMQX 5.0 中引入了一个 eq 语法，例如 eq a/b/${username}/c/d。 这样规则将会不做替换，而是保持 MQTT 主题 a/b/${username}/c/d 不变。
通过利用主题占位符的特性，动态的指定客户端ID，进行主题拼接，那么就可以解决之前提到的问题：用户不会误关闭邻居家的灯泡，因为下发指令时指定了特定的设备ID，而设备订阅的主题跟当前设备ID相关。因此利用了Topic设计上的小技巧，解决了一个实际的难题。
HTTP授权实例
HTTP Authorizer 将授权的请求委托给外部 HTTP 服务器。
基本原理
- 在 Authorizer 的配置中，预先定义好 HTTP 服务器的URL以及请求的模版。
- 当一个客户端需要执行发布或者订阅操作时候，EMQX 根据预先定义的模版来构造一个 HTTP 请求，并发送给配置的 HTTP 服务器。
- 通过判断服务器返回的 HTTP 状态码或者消息体来判定是否对发布/订阅请求授权。
应答格式
Content-Type必需是application/json- 当前 HTTP 返回状态码为 200 时，认证结果取决于 HTTP Body 中的 result 字段：
allow：允许此次发布/订阅。deny：拒绝此次发布/订阅。ignore：忽略本次请求，把它移交给下一个 Authorizer 处理。
- HTTP 返回状态码
204表示允许此次发布/订阅请求。
DashBorad配置
点击 访问控制 -> 授权 -> 创建
Http 服务端代码
package main
import (
"github.com/gin-gonic/gin"
"io"
"net/http"
"os"
)
type Auth struct {
Username string `json:"username"`
}
func main() {
gin.DefaultWriter = io.MultiWriter(os.Stdout)
r := gin.Default()
r.POST("/auth/:peerhost/:clientid", func(c *gin.Context) {
login := Auth{}
c.BindJSON(&login)
c.JSON(http.StatusOK, gin.H{
"result": "deny",
})
// 授权通过 放开以下代码
//c.JSON(http.StatusOK, gin.H{
// "result": "allow",
//})
})
r.Run(":8999")
}
授权测试
授权通过
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hrR1gs8q-1666517494665)(/Users/andy/Library/Application Support/typora-user-images/image-20221023153200619.png)]
授权通过 客户端没有爆任何异常。
授权拒绝
异常情况
在实践的过程中 有一个小细节 需要注意，http请求内部 body里面需要传输 username 属性，因此建立连接一定要输入用户名，否则就会报错:
2022-10-23T15:13:03.929000+08:00 [warning] authorize_type: http, clientid: mqttx_b2bbc267, line: 400, mfa: emqx_authz:do_authorize/4, msg: placeholder_interpolation_failed, peername: 192.168.0.30:49264, placeholder: <<"username">>
2022-10-23T15:18:32.228000+08:00 [warning] authorize_type: http, clientid: mqttx_b2bbc267, line: 400, mfa: emqx_authz:do_authorize/4, msg: placeholder_interpolation_failed, peername: 192.168.0.30:49264, placeholder: <<"username">>
2022-10-23T15:19:15.684000+08:00 [warning] authorize_type: http, clientid: mqttx_b2bbc267, line: 400, mfa: emqx_authz:do_authorize/4, msg: placeholder_interpolation_failed, peername: 192.168.0.30:49264, placeholder: <<"username">>
黑名单机制
EMQX 为用户提供了黑名单功能，用户可以通过 Dashboard 将指定客户端、用户名加入黑名单以拒绝该客户端访问，除了客户端标识符以外，还支持直接封禁用户名甚至 IP 地址。
点击菜单 访问控制 -> 授权 -> 创建 按钮，如下图
跟期望的一样，客户端连接的时候，出现接拒绝错误。
黑名单HTTP 优先级问题
既然黑名单、HTTP服务器都可以拒绝客户端连接，那么他们之间的优先级如何确定？测试一波.
1、创建HTTP服务器认证 并开启
首先，单独测试下，http 认证服务是否正常运行。
- 创建一个根据用户名 过滤的黑名单，过滤值为kobe的用户登录。
- 客户端连接，看是否调用http 认证服务。
如上图所示，HTTP 认证服务并没有任何日志输出。因此可以得到结论。黑名单的执行顺序优先与HTTP 认证服务。