A few days earlier we’ve released Viinex build 188.8.131.527 which contains the implementation for access control lists. That is, in contrast with previous versions where Viinex only required a remote client to authenticate (if ever) in order to provide full access to all objects published within respective network server component, — this new feature suggests that different users may be assigned one or more different roles, while roles may be granted with permissions to access certain functionality on certain Viinex objects.
This allows for deploying Viinex in quite advanced scenarios where, for example, the access rights to view a live video stream may be granted to one group of users, the rights to access video archive — to another group, controlling a PTZ may require a separate privilege, and so on. Additionally, all of these privileges can be set up for specific Viinex objects.
Another novel is that the ACL-related information can now be stored not only in Viinex configuration or htdigest files, but also in a relational database, and can be changed in runtime, e.g. a Viinex cluster needs not be restarted in order for users to be added or removed, or to access rights to be changed. Such changes can now be performed using Viinex HTTP API.
To keep the configuration structure logic clear, we made a breaking change to its format: instead of the “auth” sections for HTTP and RTSP server, there’s now a new “authnz” object which is responsible for doing all the authentication and authorization job. This new object needs to be created in the configuration, and linked with the server objects which provide access to users over network, — that’s HTTP, RTSP and WebRTC components. Because of this change, we decided to bump Viinex version number to the value of 3.1.
Last but not least, — the access control lists are expressed in terms of so-called “endpoint types” in Viinex. Endpoint types may be viewed as tags to classify the behavior of components. “VideoSource”, “TimelineProvider” and “PtzControl” are examples for such tags. This is a concept which is for the first time introduced with this release, and although the “endpoints” were always there, — we never mentioned or documented them explicitly. Now this is changed, — our documentation was essentially updated. A few new important sections were added, which we believe would help understanding the formal rules of how Viinex configuration is interpreted, — so we encourage the developers who use Viinex in their software to check out the updated user’s guide.