RBAC

Role Based Access Control (RBAC) is a model for giving a user access to one or more resources.
NIST CSRC RBAC is the de facto implementation .

Introduction

RBAC is an access control mechanism which:

• Describes complex access control policies,
• Reduces errors in administration,
• Reduces cost of administration.

RBAC

Entity Relationship

The NIST RBAC Model uses a limited set of concepts to define an RBAC system as depicted below. The system has (1) users, users have (2) sessions and sessions and users have (3) roles assigned to them. Each role consist of (4) permissions and permissions are based on (5) objects and (6) operations. Optional you can use the modal without Sessions. Instead of sessions the user may have an access-token that expires after a certain time period.

The model contains 6 main entities: user: this contains all the user data session: this contains the session data for all currently logged on users role: this contains all the roles that are defined permissions: this contains all the permissions based on objects and operations object: objects are the items that require protection operation: operations are the actions that are performed on the objects

1. Model and Entity Relation taken from Mind-it .
2. Model Database: https://www.mind-it.info/wp-content/uploads/2011/06/mysql_5.txt
3. Model PHP: https://www.mind-it.info/2009/10/02/a-query-engine-for-php

Examples

As always an example makes more clear than anything else.

Generic example

Suppose we take a generic app as an example. The following fictive user and roles are defined:

User Role Harm Admin Riet Writer Jan Reader Guest Guest

Role Permission Object Admin CRUD tabHome CRUD tabInput CRUD tabAdmin Writer RU tabHome RU tabInput   tabAdmin Reader R tabHome R tabInput   tabAdmin Guest R tabHome R tabInput   tabAdmin

Specific example

The above generic example has a few disadvantages.

1. The application may have different roles for different occurrences in an application.
2. The object may have different roles for specific objects inside an application.

In case of the application Energy the user may have different houses and have different roles on those houses. I call that a filter.

User	Role	Filter
Harm	Admin	NOH-116
	Admin	AadR-2
	Admin	OST-16
Riet	Writer	NOH-116
	Reader	AadR-2
		OST-16
Jan		NOH-116
		AadR-2
	Writer	OST-16

And the second in the permissions and objects:

Role	Permission	Filter	Object
Admin	CRUD	*	tabHome
	CRUD	*	tabAdmin
Writer	RU	Energy	tabInput
	R	Energy	tabAdmin
Reader	R	*	tabInput
		*	tabAdmin

As can be seen easily the filter has an improvement on the user-role-filter, but does makes the permission objects a mess.
Therefor:

1. An extra table has to be created for the filter in the User-Role-Filter.
2. The Permissions and objects needs to be made in a specific application-class.

See also

• NIST CSC RBAC, National Institute of Standards and Technology (NIST), Computer Security Resource Center (CSRC) Role Base Access Control (RBAC) Presentation.