Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Valentina Casola » 6.Role Based Access Control standard (v3)


Role-Based Access Control

User’s change frequently, Roles don’t.

User's change frequently, Roles don't.


Privilege

  • Roles are engineered based on the principle of least privileged
    • A role contains the minimum amount of permissions to instantiate an object.
  • A user is assigned to a role that allows him or her to perform only what’s required for that role.
  • No single role is given more permission than the same role for another user.

Role and transactions

  • A role can be thought of as a set of transactions that a user can perform within the context of an organization.
  • Note that the term transaction is used to extend the actions to not only read/write ones but to all actions that a user can perform on both functions and data (data absraction model).

Users, roles and security principles

  • Least Privilege.
  • Separation of Duty (SoD).
  • Separation of administration and access.
  • Abstract operations (Data abstraction).

Formal description

3 key concepts:

  • Active Role: AR().
  • Role set: RA().
  • Transaction authorized per role: TA().

For each subject, the active role is the one that the subject is currently using: AR(s: subject) =  { the active role for subject s }.

Each subject may be authorized to perform one or more roles: RA(s: subject) = { authorized roles for subject s }.

Each role may be authorized to perform one or more transactions: TA({r: role)} = {transactions authorized for role r}.

Basic rules

  1. Role Assignment:
    A subject can execute a transaction only if the subject has selected or been assigned a role: ∀s: subject, t: tran(exec(s,t) → AR(s) ≠ 0).
  2. Role Authorization:
    A subject’s active role must be authorized for the subject: ∀s: subject(AR(s) ⊆ RA(s)).
  3. Transaction Authorization:
    A subject can execute a transaction only if the transaction is authorized for the subject’s active role: ∀s: subject, t: tran(exec(s,t) → t ∈ TA(RA(s))).

RBAC standard v3

  • Core Components.
  • Constraining Components
    • Hierarchical RBAC
      • General.
      • Limited.
    • Separation of Duty Relations
      • Static.
      • Dynamic.

Core Components

Defines:

  1. Users.
  2. Roles.
  3. Operations (Ops).
  4. Objects (obs).
  5. User Assignments (ua): assigned_users.
  6. Permissions (prms)
    • Assigned Permissions.
    • Object Permissions.
    • Operation Permissions.
  7. Sessions
    • User Sessions.
    • Available Session Permissions.
    • Session Roles.

Core RBAC


USERS and ROLES

ROLE: An organizational job function with a clear definition of inherent responsibility and authority (permissions).

ROLE: An organizational job function with a clear definition of inherent responsibility and authority (permissions).


Operations and Objects

Operations

  • Database –> Update Insert Append Delete.
  • Locks –> Open Close.
  • Reports –> Create View Print.
  • Applications -> Read Write Execute.

Objects
An entity that contains or receives information

  • OS Files or Directories.
  • DB Columns, Rows, Tables, or Views.
  • Printer.
  • Disk Space.
  • Lock Mechanisms.

User Assignment


Permissions

The set of permissions that grants the approval to perform an operation on a protected object.

The set of permissions that grants the approval to perform an operation on a protected object.


PA: Permissions Assignment

Mapping of permissions to objects.

Mapping of permissions to objects.


PA: Permissions Assignment (cont’d)


RH (Role Hierarchies)

  • Natural means of structuring roles to reflect organizational lines of authority and responsibilities.
  • General and Limited.
  • Define the inheritance relation among roles
    i.e. r1 inherits r2.

Tree Hierarchies


General RH


Limited RH

A restriction on the immediate descendants of the general role hierarchy.

A restriction on the immediate descendants of the general role hierarchy.


Constrained RBAC


Separation of Duties

  • Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level of authority for their position.
  • Ensures that failures of omission or commission within an organization can be caused only as a result of collusion among individuals.
  • Two Types
    • Static Separation of Duties (SSD).
    • Dynamic Separation of Duties (DSD).

SSD

  • SSD places restrictions on the set of roles and in particular on their ability to form UA relations.
  • No user is assigned to n or more roles from the same role set, where n or more roles conflict with each other.
  • A user may be in one role, but not in another—mutually exclusive.
  • Prevents a person from submitting and approving their own request.

SSD in Presence of RH

  • A constraint on the authorized users of the roles that have an SSD relation.
  • Based on the authorized users rather than assigned users.
  • Ensures that inheritance does not undermine SSD policies.
  • Reduces the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles.

DSD

  • Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential prms that can be made available to a user.
  • Constraints are across or within a user’s session.
  • No user may activate n or more roles from the roles set in each user session.
  • Timely Revocation of Trust ensures that prms do not persist beyond the time that they are required for performance of duty.

Distributed RBAC Architectures

  • Server pull architecture.
  • User pull architecture.
  • Proxy-based architecture.

Policy-based access control mechanisms


Why Policies?

  • Aggregate users.
  • Aggregate resources.
  • Aggregate simple security statements.

Access Control Model and Role Management

  • Access Control Model based on attributes of users and on attributes of objects (different external conditions). There is the need of a model to better represent the structure of an organization or the relations btw users.
  • Role could not be expressed just as a static member of a group.
  • RBAC.

Open issues:

  • People don’t understand complex systems or complex policies.
  • it is hard work to map user security statements in enforceable policies.

Further Readings and references

  • Access Control Mechanisms – CAP 15, Matt Bishop
    • Access Control Lists.
    • Capability lists.

Sun’s XACML Implementation:

  • XACML Core Specification Documents [access_control-xacml-2.0-core-spec-os.pdf].
  • Survey on XML-Based Policy Languages for Open Environments [Mariemma I. Yagüe].

I materiali di supporto della lezione

Access Control Mechanisms - CAP 15, Matt Bishop.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion