In this quick tutorial, we will cover Evaluating Catenis Permission Levels. In this tutorial, you’ll learn about the different permission rights levels used by Catenis Flow nodes and how permissions are evaluated in relation to these levels.
In this video we will cover:
Prerequisite
After watching Understanding How Permissions Work for Decentralized Systems, feel free to watch the next video, Permission Events, to further expand your knowledge.
Subscribe to our channel for more Bitcoin Blockchain building videos! https://www.youtube.com/c/BlockchainofThings
Links from this video for easy access:
To sign up for your free account, head to our website www.blockchainofthings.com.
Join our community forum for the quickest response time to all your questions and concerns. This forum is our customer support. https://forum.blockchainofthings.com/
[Music]
Hi, this is Claire for Blockchain of Things.
In this tutorial, you’ll learn about the different permission rights levels used by Catenis Flow Nodes,
and how permissions are evaluated in relation to these levels.
Before continuing with this tutorial, make sure you’ve checked out the previous tutorial
titled “How Permissions Work for Decentralized Systems”.
Okay!
Let’s get started!
All rights across permission events can be set at four levels.
Permission events can be set to either allow,
deny,
or once set,
they can be unset, or cleared.
The system level is unique, because permissions can only be toggled from allow to deny, or vice versa.
The permission at this level cannot be cleared.
The system level controls permission rights across the entire Catenis network,
where the default permission rights are defined.
Setting permission rights at a higher level will affect how all virtual devices within the context of that level
and levels below, can or cannot interact with the subject device.
For example, permissions set at the node level will affect all
devices across all clients within that node,
if there are no other more granular permissions set.
The Catenis Node level controls the permission rights for all
devices that belong to all clients defined for that Catenis Node.
Catenis Nodes are called “gateways” and there is only one central cloud-based hub.
The hub, and each gateway has a specific index number.
If you are using our cloud implementation, the index number is always zero.
The client level controls the permission rights for all devices that belong to a given client.
Clients, are Catenis system entities within a Catenis Node.
A hub or gateway, for instance, may have one or more clients.
The virtual device level is the most granular level at which you can set permissions
and controls the permission rights for a specific virtual device.
Now that you know the different permission rights levels,
let’s take a look at how permissions are evaluated.
Setting permission rights at a higher level will affect how all virtual devices within the context of that level
and levels below,
can or cannot interact with the subject device.
For example, permissions set at the node level will affect all devices across
all clients within that node.
However, the system evaluates permissions giving precedent to the more granular virtual device levels over the very broad system level.
The system first looks to see if a device is allowed or denied permission for a permissioned event.
If there are no permissions set then it evaluates the next level,
which is the client level,
then the Catenis Node level,
and finally, the system level.
At first glance, it may seem that it is possible to set conflicting
permissions within the permissions hierarchy.
However, this is not the case.
This is because permissions that are set at a more granular level
will always override what is set at a higher level.
Let’s review an example,
you may set the Receive Asset From Permission Event for virtual device “A” to “deny” for all devices at the Catenis Node level.
This means virtual device “A” will not be able to
receive any assets from any device that is part of that Catenis Node.
However, if you had previously set the same
Receive Asset From Permission Event for virtual device “B”,
at the virtual device level to “allow”,
then device “A” will be allowed to receive assets from device “B”.
Even though device “B” is part of the same Catenis Node, you previously denied access to all devices.
If you’re ever in doubt, use the Check Effective Permission Rights Node, using the subject device to connect,
and supplying the device ID of the device that is attempting to execute a permission event with the subject device.
You’ll learn how to use the Check Effective Permission Rights Node in a subsequent video.
Awesome!
Now, you should have a basic understanding of the Catenis Permission System.
and you’re ready to learn about the four types of Permission Nodes.
[Music]