FiFo uses Snarl as a AAA system with that comes the option of a very fine grained and powerful Authorization scheme. Every operation performed checks against one or more permissions. Those permissions are stored in a tree like structure, where each permission is a path from root to leave in the tree. For readability we will use the notation root->branch->branch->leave here to represent this path or in other words the associated permission.

The levels in the tree go from the most general part towards the most specific one, so for example cloud->datasets->list goes from cloud, the most general part of the permission towards list the most specific one.

This allows for a rather powerful use of wildcards in permissions. There are two types of wildcards Snarl supports.

• ... which represents everything beyond this branch of the tree.
• _ which represent everything on this level of the tree

For example cloud->_->list would allow list on every thing under cloud, so cloud->users->list, and cloud->roles->list and so on. While cloud->users->... would allow everything under cloud->users so cloud->users->list, cloud->users->create and also on deeper levels cloud->users->set_on->fire and cloud->users->set_on->ice. The ... wildcard can only be used as the last element of a permission, while the _ permission can be used both as the last element and as a element somewhere in the middle.

Users and roles

An account (or user) is the main entity that is used. Snarl uses a RBAC based system however, that allows representing frequently used permissions in roles that will grant their permissions to users who obtain the role in question. As a result there are two ways of granting a permission to a user. It is important to understand that a user can, and in most cases will, belong to more then one role to represent their full permission set.

1. Directly, a user can have permissions that are granted to him and only him. This is convenient in some cases where a single user is getting a permission that isn't normally granted inside of any role.
2. Indirectly Via a role, that applies the permission to all users who have the role in question.

A permission granted to a role will apply to all users with the role, even those that received the role before the permission was granted. In the same way a permission revoked will be revoked from all users in this role imedeately.

🚧

Revoking permissions

Please consider that revoking a permission is not the same as dining a permission, and that the same permission can be obtained through multiple paths - be it by having wildcards or by having the same permission in two roles. So for example a user belonging to two roles that contain permission A will still have permission A even if it is revoked from one of the roles!

Organizations

Organizations are Snarls method of distributing new permissions. Since the control over things is very fine grained permissions are generated on the fly as new entities are created. To archive that actions carried out by a user are done so 'in the name of' an organization, representing the concept that users are acting as agents of an organization and not on their own accord.

When certain action is performed in the name of an organization they execute triggers on it, allowing the organization to control how the actions affect permissions. The core concept here is that when a new entity is created, for example a VM, the organization can control what permissions are created inside of different roles.

This allows to create organization specific rules, for example an admin rule for an organization could receive full control over all VMs created for this organization, while a read only rule could receive only read permissions on them.

Accounting records are also written on the behalf of organization, creating, updating or destroying a VM in the name of the organization will create the according record.

Users can belong to more then one organization however they can only act as agent for one of them at a time but swap between them in between. For example a DevOps engineer could manage systems for both the HR and the Dev department of a company, each represented as their own organization. They would then switch between the two organization depending on which they are carrying a task out for.

OAuth2, clients and scopes

With v0.7.0 fifo introduces a full OAuth2 authentication schema, in that sense it allows for clients and scopes to be used when carrying out actions. When a user is authenticated via a client the requested scope will be taken into account of what actions are permitted.

While roles are additive, as in a user is having a permission when any of their roles has the permission scopes are the opposite. When using a scoped client a permission is only given when both the scope permit the action and the user (or any of their roles) permit the action.

Permissions

The following list describes the permissions used in FiFo.

Datasets

Dataset Permissions start with datasets-> followed by the UUID of the dataset. In addition to user specific permissions the following cloud global permission exist.

cloud->datasets->list

Allows to list datasets, the get permission on each dataset determines which users are seen during the list.

cloud->datasets->create

Allows the to create new datasets.

datasets-><UUID>->get

Allows to see the dataset/read it's data.

datasets-><UUID>->delete

Allows to delete the dataset.

datasets-><UUID>->edit

Allows to change the dataset.

D-Trace

D-Trace Permissions start with dtraces-> followed by the UUID of the dtrace. In addition to user specific permissions the following cloud global permissions exist.

cloud->dtraces->list

Allows to list dtraces, the get permission on each dtrace determines which users are seen during the list.

cloud->dtraces->create

Allows the to create new dtraces.

dtraces-><UUID>->get

Allows to see the dtrace/read it's data.

dtraces-><UUID>->delete

Allows to delete the dtrace.

dtraces-><UUID>->edit

Allows to change the script.

dtraces-><UUID>->stream

Allows to run this script.

Hypervisors

Hypervisor Permissions start with hypervisors-> followed by the UUID of the hypervisor. In addition to user specific permissions, the following cloud global permissions exist.

cloud->hypervisors->list

Allows to list hypervisors, the get permission on each hypervisor determines which users are seen during the list.

cloud->hypervisors->create

Allows the to create new hypervisors.

hypervisors-><UUID>->get

Allows to see the hypervisor/read it's data.

hypervisors-><UUID>->delete

Allows to delete the hypervisor.

hypervisors-><UUID>->edit

Allows to change the hypervisor.

hypervisors-><UUID>->create

Allows to create VM's on this hypervisor.

IP-Ranges

IP-Range Permissions start with ipranges-> followed by the UUID of the iprange. In addition to user specific permissions, the following cloud global permissions exist.

cloud->ipranges->list

Allows to list ipranges, the get permission on each iprange determines which users are seen during the list.

cloud->ipranges->create

Allows the to create new ipranges.

ipranges-><UUID>->get

Allows to see the iprange/read it's data.

ipranges-><UUID>->delete

Allows to delete the iprange.

ipranges-><UUID>->edit

Allows to change the iprange.

Networks

Network Permissions start with networks-> followed by the UUID of the network. In addition to user specific permissions, the following cloud global permissions exist.

cloud->networks->list

Allows to list networks, the get permission on each network determines which users are seen during the list.

cloud->networks->create

Allows the to create new networks.

networks-><UUID>->get

Allows to see the network/read it's data.

networks-><UUID>->delete

Allows to delete the network.

networks-><UUID>->edit

Allows to change the network.

Packages

Package Permissions start with packages-> followed by the UUID of the package. In addition to user specific permissions, the following cloud global permissions exist.

cloud->packages->list

Allows to list packages, the get permission on each package determines which users are seen during the list.

cloud->packages->create

Allows the to create new packages.

packages-><UUID>->get

Allows to see the package/read it's data.

packages-><UUID>->delete

Allows to delete the package.

packages-><UUID>->edit

Allows to change the package.

VMs

VMs Permissions start with vms-> followed by the UUID of the VM. In addition to user specific permissions, the following cloud global permissions exist.

cloud->packages->list

Allows to list packages, the get permission on each package determines which vm are seen during the list.

cloud->packages->create

Allows the to create new Vm.

vms-><UUID>->get

Allows to see the VM/read it's data.

vms-><UUID>->delete

Allows to delete the VM.

vms-><UUID>->edit

Allows to change the VM.

vms-><UUID>->start

Allows to start the VM.

vms-><UUID>->stop

Allows to stop the VM

vms-><UUID>->reboot

Allows to reboot the VM.

vms-><UUID>->console

Allows access to the VMs Console or VNC, also implies full access to all SSH users.

vms-><UUID>->ssh-><USER>

Allows the the access to SSH into the given user (i.e. <USER> could be root)

vms-><UUID>->snapshot

Allows to take a snapshot.

vms-><UUID>->rollback

Allows to rollback a snapshot.

vms-><UUID>->snapshot_delete

Allows to delete a snapshot

vms-><UUID>->backup

Allows to create a backup.

vms-><UUID>->rollback

Allows to rollback a backup.

vms-><UUID>->backup_delete

Allows to delete a backup.

Users

User permissions start with users-> followed by the UUID of the user. In addition to user specific permissions the following cloud global permission exist.

cloud->users->list

Allows to list users, the get permission on each user determines which users are seen during the list.

cloud->users->create

Allows the to create new users.

users-><UUID>->get

Allows to see the user/read it's data.

users-><UUID>->delete

Allows to delete the user.

users-><UUID>->edit

Allows to change the user.

users-><UUID>->passwd

Allows to change the password of the user.

users-><UUID>->grant

Allows to grant a permission to the user.

users-><UUID>->revoke

Allows to revoke a permission from the user.

users-><UUID>->join

Allows to have the user join a role.

users-><UUID>->leave

Allows to remove the user from a role.

Roles

Role permissions start with roles-> followed by the UUID of the role. In addition to user specific permissions the following cloud global permission exist.

cloud->roles->list

Allows to list roles, the get permission on each role determines which users are seen during the list.

cloud->roles->create

Allows the to create new roles.

roles-><UUID>->get

Allows to see the role/read it's data.

roles-><UUID>->delete

Allows to delete the role.

roles-><UUID>->edit

Allows to change the role.

roles-><UUID>->grant

Allows to grant a permission to the role.

roles-><UUID>->revoke

Allows to revoke a permission from the role.

roles-><UUID>->join

Allows to have a user join the role.

roles-><UUID>->leave

Allows to remove a user from the role.

Organisations

Role Permissions start with orgs-> followed by the UUID of the organisation. In addition to user specific permissions the following cloud global permission exist.

cloud->orgs->list

Allows to list organisations, the get permission on each organisation determines which users are seen during the list.

cloud->orgs->create

Allows the to create new organisations.

orgs-><UUID>->get

Allows to see the organisation/read it's data.

orgs-><UUID>->delete

Allows to delete the organisation.

orgs-><UUID>->edit

Allows to change the organisaiton

Clients

client permissions start with clients-> followed by the UUID of the client. In addition to client specific permissions the following cloud global permission exist.

cloud->clients->list

Allows to list clients, the get permission on each client determines which clients are seen during the list.

cloud->clients->create

Allows the to create new clients.

clients-><UUID>->get

Allows to see the client/read it's data.

clients-><UUID>->delete

Allows to delete the client.

clients-><UUID>->edit

Allows to change the client, including changing the secret.

clients-><UUID>->grant

Allows to grant a permission to the client.

clients-><UUID>->revoke

Allows to revoke a permission from the client.