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
 
 
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