Introduction to RBAC

Wojciech Sliwinski BE/CO for the RBAC team25/04/2013

W.Sliwinski - Introduction to RBAC

Purpose of RBAC

Motivation for RBAC Machine Safety▪ Enormous energy stored in the LHC magnets and

beams▪ Potential machine damage is a serious concern▪ Prevent from invoking machine protection systems

Machine Performance▪ Do not mess with a fine tuned system ▪ Access denied during certain machine states

Commissioning feedback ▪ Hardware and software commissioning▪ Debugging

25/04/2013 2

W.Sliwinski - Introduction to RBAC

Scope of RBAC

RBAC infrastructure provided by CO Does not prevent hackers from doing damage Protects against human mistakes▪ A well meaning person from doing wrong thing at the

wrong time▪ An ignorant person from doing anything at anytime

Original scope: LHC machine Can be deployed anywhere in the Controls

Infrastructure Aims to enhance the overall Machine Safety Provides Authentication (A1) and Authorization (A2)

services Complements▪ Hardware Protection (BIS, PIS)▪ CNIC effort (access control into Technical Network) ▪ MCS (Management of Critical Settings)

25/04/2013 3

W.Sliwinski - Introduction to RBAC25/04/2013 4

P. Charrue: RBAC Review ABMB - 02/04/2007

W.Sliwinski - Introduction to RBAC 5

RBAC architecture

25/04/2013

W.Sliwinski - Introduction to RBAC 625/04/2013

A1 – RBAC Authentication

A2 - RBAC Authorization

BE Control System

W.Sliwinski - Introduction to RBAC 7

RBAC Modes

RBAC has 3 modes NO-CHECK▪ As it says, no checks are made

LENIENT▪ A token is needed ONLY if a property is protected in an

access map STRICT▪ A token is MANDATORY▪ All SET properties have to be protected

25/04/2013

W.Sliwinski - Introduction to RBAC

Sharing of responsibility

CO Provides the RBAC tool and the infrastructure (CMW,

FESA,...) Support for OP and Equipment groups Proposes general recommendations▪ Naming and usage of Roles▪ Preparation of Access Rules

OP OP in collaboration with CO and Equipment groups (LHC

Controls Security Panel) defines policy for deployment of RBAC

Equipment groups Prepare and maintain Access Rules ▪ Following defined policy

Deploy Access Maps25/04/2013 8

Ordinary Roles Ordinary Roles

Can be assigned to any user Optionally specify role’s lifetime

▪ Token lifetime bound by role’s lifetime (relative)▪ Role’s lifetime is global for all assigned users

25/04/2013 W.Sliwinski - Introduction to RBAC 9

Role’s lifetime

Temporary Roles Temporary Roles (e.g. Piquet Roles)

Assign (e.g. EIC on shift) certain role for duration of intervention Specify absolute expiration time (short period) Expiration time registered in CCDB Token’s lifetime bound by role’s expiration time (absolute) After expiration, role will not be given any more in a token

25/04/2013 W.Sliwinski - Introduction to RBAC 10

Role’s expiration

time

Temporary Roles

Name convention for Piquet Roles XX-LHC-Piquet (e.g. BT-LHC-Piquet, PO-LHC-

Piquet) NO users in these ROLES except when needed

Requested by OP & PO groups Hardware interventions during operations Roles for temporary staff, contractors, etc.

25/04/2013 W.Sliwinski - Introduction to RBAC 11

Critical Roles

Critical Roles (MCS Roles) Short lifetime roles with elevated level of access rights Give access to critical equipment (e.g. BLMs, Kickers, Coll.) Should be only used by eqp. Experts and selected Operators MCS Roles already widely used for control of critical equipment Moreover RBAC provides:▪ Critical Roles management▪ Public & Private keys management for Critical Roles▪ Service for signing the equipment settings

Issues when using Critical Roles Short role’s lifetime (10 min) bounds the whole token’s lifetime Not acceptable by users who need valid token for long time▪ Users have to re-login frequently

25/04/2013 W.Sliwinski - Introduction to RBAC 12

Critical Roles

Proposed improvements (Java Client & A1 Server) User always requests Master & Application tokens Master token’s lifetime is fixed (8h), it represents user’s

session Critical Roles not included in a token after initial login▪ Critical Role has to be requested explicitly (RolePicker)▪ Only one Critical Role can be present in a token

Master token’s creation time and role’s lifetime used to verify if a certain Critical Role can be obtained at a given moment▪ Protection of Critical Roles against malicious and/or accidental use

Requested by OP group

25/04/2013 W.Sliwinski - Introduction to RBAC 13

Roles Summary

Operator Role Can always access equipment but only from CCC

Expert Role NON-OPERATIONAL mode: access from any Location OPERATIONAL mode: access only from CCC

Piquet Role Can always access equipment, from any Location Role is normally empty (not assigned) EIC assigns it only for a duration of an intervention

25/04/2013 W.Sliwinski - Introduction to RBAC 14

Virtual Devices in CCDB

Virtual Devices Convenient way to model non-hardware quantities Represent non-hardware info using class/device/property model

CCDB – master source of all Device related data

New support for Virtual Devices (DM section) Extension to CCDB data model Population via CCDB Data Editor forms Generic db view for external clients (e.g. import into LSA db) Possible to define RBAC rules (needed for MCS)

Use cases SIS (Software Interlock System) Interlock Thresholds

Requires RBAC MCS Role and access rule Import of virtual devices into LSA db SIS Interlocks protected by MCS (part of LSA)

Any virtual MCS setting in LSA, DIAMON properties, etc.. More to come ...

25/04/2013 W.Sliwinski - Introduction to RBAC 15

W.Sliwinski - Introduction to RBAC 16

Current Status

RBAC is deployed CERN-wise together with CMW & FESA

All major applications have a token RBAC mode is STRICT for LHC RBAC mode is LENIENT for the injectors

CO diagnostic and monitoring tool (DIAMON) uses RBAC on the GUI level to protect specific actions (e.g reboot, wreboot, repair)

25/04/2013