Authentication and Authorization using VerneMQ webhooks plugin
How to implement Authentication and Authorization of clients using VerneMQ Webhooks plugin using a HTTP interface
INTRODUCTION
Hubble Connected, ISO 27001:2013 certified & GDPR compliant is a connected, digital baby tech & smart living IOT platform that empowers first time parents and families to access even the most complex technology with ease. Getting pregnant and starting your own family is exciting, yet stressful. Hubble’s ambition is to get users connected and become their smart & reliable companion during their life journey; from pregnancy, through birth, toddler years, to building a bigger family and beyond.
With over 500K online cameras communicating with the Server and Application via MQTT protocol, Hubble Connected uses VerneMQ broker with SSL/TLS layer that allows clients to securely connect , publish and subscribe to various topics within Hubble eco system.
In order to achieve enhanced security, VerneMQ webhooks plugin can be implemented to authenticate connecting clients by validating client id, username and password. VerneMQ also supports authorization of publish and subscribe topics for every connected client.
You can register an HTTP API(endpoint) with a VerneMQ plugin hook and whenever the hook (such as auth_on_register, auth_on_publish, auth_on_subscribe) is called, the VerneMQ Webhooks plugin dispatches a HTTP post request to the registered endpoint.
VerneMQ currently supports various other webhooks which can be implemented accordingly.
APPROACH
The auth_on_register, auth_on_publish, auth_on_subscribe hooks are implemented in a Java Springboot application as REST API endpoint. This application runs locally on every node in the cluster in order to handle the authenticate and authorize of connecting clients and their publish and subscribe respectively.
The Java application also checks if the connecting client is valid camera or Application. In case the connecting client is not a valid camera or Application then that client is not allowed to connect to the broker.
Client credential details such as client id , username, password , allowed publish and subscribe topics are persisted in Redis Cache, this credential data is used to validate against the hook data of the connecting clients. However if the credential data is not available in the Redis Cache, an external API call is made to check if the client is valid and populate the credential data.
ENDPOINT SPECS
auth_on_register
Request Body
Response Body
auth_on_publish
Request Body
Response Body
auth_on_subscribe
Request Body
Response Body
VERNEMQ CACHING
To speed up authentication and authorization tremendously, VerneMQ supports internal caching of the hook data for the connecting clients. All data passed to these hooks is used to lookup if the call is available in the ETS(Erlang term storage) cache, although in the case of the auth_on_publish the payload is ommitted. If the lookup is available then webhook endpoints are not called.
To enable caching for an endpoint simply return the cache-control: max-age=AgeInSeconds in the response headers to one of the mentioned hooks on successful authentication or authorization.
It is possible to inspect cache stats table by using
$ vmq-admin webhooks cache show
The above table tells us
- entries → The number of entries available in verne cache
- misses → The number of times the verne cache call was missed and webhook API call was made
- hits → The number of times the verne cache was hit instead of calling the webhook API
CACHING MEMORY CONSUMPTION
As per VerneMQ documentation, Cache entries are currently not actively disposed after expiry and will remain in memory.
The hook data is cached internally by VerneMQ in memory of every node in ETS table. If the connecting clients are load balanced over the cluster on every connect/disconnect or if the client id, client ip, username, password are changed, then a new entry is created in the ETS table. Hence over a period of time the nodes may get into OOM (out of memory) and the can cause a DT(Down time).
To avoid this, the webhooks cache stats reset command was tweaked to reset both the webhooks hits, entries, misses stats table along with the webhook cache table.
$ vmq-admin webhooks cache show — reset
If the memory reaches the threshold of 80 % then the above command can clear the memory on the nodes.
WORKFLOW
REFERENCES
