Role based access control

This section is a practical application of stdnet for solving role-based access control (RBAC). It is an approach for managing users permissions on your application which could be a web-site, an organisation and so forth.

Introduction

There are five different elements to get familiar with this RBAC implementation:

• System: this is your application/organization/web site.
• Roles: within a system, roles are created for various operations.
• Permissions: they represents the power to perform certain operations on a resource and are assigned to specific roles within a system.
• Operations: what can a user do with that permission, usually, read write, delete.
• Subjects: these are the system users which are assigned particulr roles. Permissions are not assigned directly to subjects, instead they are acquired through their roles.

The Permission to perform certain certain operations are assigned to specific roles.

This example is manages Users, Groups and Permissions.

Roles

In this implementation a role is uniquely identified by a name and a owner.

class examples.permissions.Role(*args, **kwargs)

A Role is uniquely identified by its name and owner.

name = None

The name of this role.

owner

The owner of this role-permission.

permissions

the set of all Permission assigned to this Role.

add_permission(resource, operation)

Add a new Permission for resource to perform an operation. The resource can be either an object or a model.

assignto(subject)

Assign this Role to subject.

Subjects

The subject in this implementation is given by the Group. Therefore roles are assigned to Group. Since roles are implemented via the Role model, the relationship between Group and Role is obtained via a stdnet.odm.ManyToManyField.

class examples.permissions.Group(*args, **kwargs)

name = None

Group name. If the group is for a signle user, it can be the user username

user

A group is always owned by a User. For example the admin group for a website is owned by the website user.

users

The stdnet.odm.ManyToManyField for linking User and Group.

The system user is implemented via the User. Since roles are always assigned to Group, a User obtains permissions via the groups he belongs to.

class examples.permissions.User(*args, **kwargs)

The user of a system. The only field required is the username. which is also unique across all users.

Design

A Group is always owned by a User but several user can be part of that Group. Lets consider a web-site where we need to manage permissions and be able to query efficiently only on instances for which a Given user has enough permissions.

The first step is to register a Model, lets assume one called MyModel, with the permission engine:

register_for_permissions(MyModel)

from now on every time a new instance of MyModel is created, it must be given the user owning the instance.

First we create the website User and define a set of permissions:

website = models.user.new(username='website')

read = 10
create = 20
update = 30
delete = 40

The higher the permission level the more restrictive is the algorithm. We then create a group for all authenticated users:

authenticated = Group(name='authenticated', user=website).save()

and another group called ‘administrator’:

admin = Group(name=’administrator’, user=website).save()

We want all authenticated users to be able to read instances from model MyModel:

role = Role(name='can read my model',
            permission_level=read,
            model=MyModel).save()
role.groups.add(authenticated)

We want all admin users to be able to update instances from model MyModel but not delete them:

role = Role(name='can create/update my model',
            permission_level=update,
            model=MyModel).save()
role.groups.add(admin)

When we create a new instance of MyModel we need to give the required role

instance = MyModel(....., user=user).save()

role.add(instance)

Lets assume we have a query on MyModel and we need all the instances for user with permission level:

authenticated_query(query, user, level)