Hola! 👋
Let me know if this is not the right place to post this feature request. I'm posting this request based on this discussion: emqx/emqx#11528
Basically, with the introduction of User Properties in the V5 version of the MQTT protocol, I think it expands the possibility to enhance authentication processes by allowing the specified properties to be used as placeholders in different authentication/authorization services.
for my particular use-case, I want do to something like this:
- A client sets a User-Property of
(ApiKey, ABC123) in the CONNECT packet along with a username and a password.
- EMQx sees this and sends as a POST request a
username, password and ApiKey: ABC123 to an external HTTP service.
- The HTTP Service receives a JSON object like this:
{"username": ..., "password": ..., "apiKey": "ABC123" }.
Or expose them via headers too, so the HTTP Endpoint receives a custom header like X-API-KEY: ABC123.
Also, allowing user properties to be used as placeholders, will allow more granular control over the PUBLISH packet as well with ACLs.
Thanks!
Hola! 👋
Let me know if this is not the right place to post this feature request. I'm posting this request based on this discussion: emqx/emqx#11528
Basically, with the introduction of User Properties in the V5 version of the MQTT protocol, I think it expands the possibility to enhance authentication processes by allowing the specified properties to be used as placeholders in different authentication/authorization services.
for my particular use-case, I want do to something like this:
(ApiKey, ABC123)in theCONNECTpacket along with ausernameand apassword.username,passwordandApiKey: ABC123to an external HTTP service.{"username": ..., "password": ..., "apiKey": "ABC123" }.Or expose them via headers too, so the HTTP Endpoint receives a custom header like
X-API-KEY: ABC123.Also, allowing user properties to be used as placeholders, will allow more granular control over the
PUBLISHpacket as well with ACLs.Thanks!