Introduction to RBAC

1. Wojciech Sliwinski BE/COfor the RBAC team 25/04/2013 Introduction to RBAC

2. Purpose of RBAC • Motivation for RBAC • Machine Safety • Enormousenergy 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 W.Sliwinski - Introduction to RBAC

3. 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 ControlsInfrastructure • Aims to enhance the overall Machine Safety • ProvidesAuthentication (A1) and Authorization (A2) services • Complements • Hardware Protection (BIS, PIS) • CNIC effort (access control into TechnicalNetwork) • MCS (Management of Critical Settings) W.Sliwinski - Introduction to RBAC

4. P. Charrue: RBAC Review ABMB - 02/04/2007 W.Sliwinski - Introduction to RBAC

5. RBAC architecture W.Sliwinski - Introduction to RBAC

6. BE Control System A2 - RBAC Authorization A1 – RBAC Authentication 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 W.Sliwinski - Introduction to RBAC

8. 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 collaborationwith CO and Equipmentgroups (LHC Controls Security Panel) defines policy for deployment of RBAC • Equipment groups • Prepare and maintain Access Rules • Following definedpolicy • Deploy Access Maps W.Sliwinski - Introduction to RBAC

9. OrdinaryRoles • 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 Role’s lifetime W.Sliwinski - Introduction to RBAC

10. TemporaryRoles • 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, rolewill not be given any more in a token Role’sexpiration time W.Sliwinski - Introduction to RBAC

11. TemporaryRoles • Nameconvention 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. W.Sliwinski - Introduction to RBAC

12. CriticalRoles • 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 onlyused by eqp. Experts and selectedOperators • MCS Roles already widely used for control of critical equipment • MoreoverRBAC provides: • Critical Roles management • Public & Private keys management for CriticalRoles • 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 W.Sliwinski - Introduction to RBAC

13. 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 W.Sliwinski - Introduction to RBAC

14. RolesSummary • Operator Role • Canalwaysaccessequipment but onlyfrom CCC • Expert Role • NON-OPERATIONALmode: accessfromanyLocation • OPERATIONAL mode: accessonlyfrom CCC • Piquet Role • Canalwaysaccessequipment, fromanyLocation • Role is normallyempty (not assigned) • EICassignsitonly for a duration of an intervention W.Sliwinski - Introduction to RBAC

15. 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 ... W.Sliwinski - Introduction to RBAC

16. Current Status • RBAC is deployed CERN-wisetogether 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) W.Sliwinski - Introduction to RBAC