|
|
@@ -0,0 +1,31 @@
|
|
|
+Customizable client attributes in `clientinfo`.
|
|
|
+
|
|
|
+Introduced a new field `client_attrs` in the `clientinfo` object.
|
|
|
+This enhancement enables the initialization of `client_attrs` with specific
|
|
|
+attributes derived from the `clientinfo` fields upon accepting an MQTT connection.
|
|
|
+
|
|
|
+### Initialization of `client_attrs`
|
|
|
+
|
|
|
+- The `client_attrs` field can be initially populated based on the configuration from one of the
|
|
|
+ following sources:
|
|
|
+ - `clientid`: The MQTT client ID provided by the client.
|
|
|
+ - `username`: The username provided by the client.
|
|
|
+ - `cn`: The common name from the TLS client's certificate.
|
|
|
+ - `dn`: The distinguish name from the TLS client's certificate, i.e., the certificate "Subject".
|
|
|
+
|
|
|
+### Extension through Authentication Responses
|
|
|
+
|
|
|
+- Additional attributes may be merged into `client_attrs` from authentication responses. Supported
|
|
|
+ authentication backends include:
|
|
|
+ - **HTTP**: Attributes can be included in the JSON object of the HTTP response body through a
|
|
|
+ `client_attrs` field.
|
|
|
+ - **JWT**: Attributes can be included via a `client_attrs` claim within the JWT.
|
|
|
+
|
|
|
+### Usage in Authorization
|
|
|
+
|
|
|
+- The `client_attrs` can be utilized in authorization configurations or request templates, enhancing
|
|
|
+ flexibility and control. Examples include:
|
|
|
+ - In `acl.conf`, use `{allow, all, all, ["${client_attrs.namespace}/#"]}` to apply permissions
|
|
|
+ based on the `namespace` attribute.
|
|
|
+ - In other authorization backends, `${client_attrs.namespace}` can be used within request templates
|
|
|
+ to dynamically include client attributes.
|
zmstone