This demo is about the administration of Role Based Access Control (RBAC) systems. The AJAX Web application was developed with Java Server Faces supplemented by the PrimeFaces widget library. The administration console runs on the WildFly application server backed by a MySQL (or alternatively PostgreSQL) database.

RBAC was first described within a paper by D.F. Ferraiolo und D.R. Kuhn in 1992. Users of computer systems are assigned to one or more roles in a corporate organization. According to the performed roles of a particular user, the system may grant access privilegs to various operating resources. By way of illustration, the UML class diagram below shows partially the assocations between the most relevant entities.

A particular user may fulfill multiple roles. On the other hand a certain role may be performed by multiple users. Depending on the actual domain a particular user may own more than one session. But typically web applications allow only one session per user. A certain user might not get all of her roles assigned every time when she initiates a session. Policies may require that roles which grant extensive permissions shall be acquired only from inhouse but not from remote sessions.

This demo focuses on the administration (CRUD) of users and roles as well as the assignment of roles. Roles can be further divided into roles which are known at design time of the system and roles which can be created dynamically at runtime. The former ones can participate in the Java EE declarative security model, see e.g. Introduction to Security in the Java EE Platform. To make things more interesting the demo introduces a concept of recovery points. An operator might take a snapshot of the current database state and might roll back to this recovery point later on. Hence the main entities of the demo (user and role) must partake in some form of version control system. This demo pursues the strategy of copy-on-write. So long as a particular entity has not been changed it might be referenced by different snapshots (or versions). At the time when a change to such an entity is comitted to the database it will be copied so that the most recently created snapshot will own it exclusively. Thus, a certain entity (user or role) may be referenced by multiple snapshots and vice versa a particular snapshot may reference multiple entities, see the UML class diagram below.

That is to say, the demo application enforces the immutability of entities which are referenced by past snapshots. Snapshots can be created at any time. Newly created snapshots will initially reference those entities referenced by the previous snapshot.