Skip to content

Role Management

Lukáš Vozáb edited this page Jan 25, 2016 · 1 revision

System Management Architecture - User/Role Managment

Preface

CleverBus product doesn't provide standardized implementation for user/role relationship so that there is no possibility to define such a relations. This releations are seen as usefull when the access restriction for given resource o function must be define in CleverBus implementations.

This document is going to design such a implementation.

Reference

Ref. Description
CLVBUS-198 Related developmnet task
RBAC Role Based Access Control wiki
ACL Access Control List
RBAC vs ACL Study NIST - Comparing Simple RBAC Models and ACL's (John Barkley)
RBAC Models IEEE - RBAC Reference Models (Oct 26 1995)
JSR-250 Common Annotations for Java Platform v1.2 (Feb 15 2013)

RBAC

  • RBAC 0 - The base model, is at the bottom, indicating that it is the minimum requirement for any system that professes to support RBAC
  • RBAC 1 - Adds the concept of role hierarchies (situations where roles can inherit permissions from other roles).
  • RBAC 2 - Adds constraints (which impose restrictions on acceptable configurations of the different components of RBAC).
  • RBAC 3 - consolidated model, includes RBAC1 and RBAC2 and, by transitivity RBAC 0

RBAC models relations

Benefits

  • It provides mechanisms to secure the system againts fraud
  • It provides access control to selected resource and functionality provided by the system
  • It enables centralized user/role management
  • It directly supports three well-known security principles: least privilege, separation of duties, and data abstraction

Processing phases

The Administration phase consists of creating and maintaining user and object security attributes. Administration tools are usually privileged applications. Administration usually occurs the least often of the three phases.

The Session phase consists of establishing, changing the characteristics of, and removing sessions. A session is a set of processes, called subjects, which act on behalf of a user. Session establishment involves authenticating the user, creating one or more subjects, and associating user security attributes with each subject. The Session phase usually occurs more often than the Administration phase and less often than the Enforcement phase.

The Enforcement phase consists of comparing the user security attributes associated with the subject (i.e., the subject security attributes) to object security attributes in order to grant or deny access. The Enforcement phase occurs every time asubject attempts to access an object and is usually the most frequently occurring phase of the three.

Clone this wiki locally