LSA & Safety – Integration of RBAC and MCS in the LHC control system

1. LSA & Safety – Integration of RBAC and MCS in the LHC control system

2. RBAC – Controlling Access • What is being accessed? • Device properties (PowerConverters, Collimators, Kickers, etc.) • What typeof access? • get: the value of a property once • monitor: the value of a property continuously • set: the value of a property • Person who wants to protect devices need to know: • How to create and manage a role • How to create and manage rules (permissions) • How to load the rules (Access Maps) into the CMW servers

3. RBAC Overview T • Authentication: • User requests to be authenticated. • RBAC authenticates user via NICE user name and password • RBA returns Token to Application • Authorization: • Application sends token to Application Server (3-tier env.) • CMWclientsendstoken to CMW server • CMW server (on front-end) verifies token • CMWserver checks AccessMapfor role, location, application, mode Configuration DB Application RBAC T • RBAC Token: • Application name • User name • IP address/location • Time of authentication • Time of expiry • Roles[ ] • Digital signature (RBA private key) Application Server CMW client T CMW server Access MAP FESA

4. RBAC – Base Concepts • RBAC Token (Authentication) • Proof of authentication • Holds information for authorization: roles, location, application • Digital signature • Access Maps (Authorization) • Access maps are text files on the front-ends • They are built from the database tables holding all access rules • Default: if there are no rules for a device property it is NOT protected • Contain the subset of access rules for a specific server on the front-end • Read into memory on start-up for fast permission checks • VerifyToken’s digital signature with RBAC public key • Token came from the RBAC server • Token contents have not been altered • Check the expiration time

5. RBAC - Managing Rules and Access Maps • No automatic propagation of rules from the data base to the front-ends. • This is a manual process • Execute an RBAC script that extracts the rules from the database into text files (Access Maps) • One Access Map per device class (minimize the rules in one front-end) • Access Maps are loaded into the CMW server when starting-up the front-end • Access Maps are generated and put on the front-ends manually by equipment owners

6. RBAC - part of the LHC control system • RBAC tokens are passed through the LHC control system • RBAC token is used to check users access rights at the front-end level • For GUI developers RBAC is an easy plug-in (even for LabView applications) • For applications using LSA: use RBAIntegrator class • With the standard GUI LSA components this results in…

7. RBAC Features • Authentication by Location • We can specify that in certain location one does not have to explicitly login • The user name is the one used to login at the console • The roles are the ones associated with the user name • Single Sign On (SSO) • When SSO is enabled the user has only to log in once at a certain PC and is automatically logged in for all applications running on that PC • Role Picker • Additional dialog for pickinga specific role if user has multiple ones • Dealing with critical settings • Generation and managementof public and private keys • User is forced to login even if he is at a location where Authentication by Location is enabled (Authentication by location override) • Only one criticalrole can be selected when trimming critical settings

8. MCS in LHC controls • MCS is integrated with core LHC controls systems: LSA and FESA • MCS is part of LSA: • Critical settings and their signatures are in the LSA database • Managed in a common way like other settings but additionally require signing • Signature generation uses RBAC API for private-public key management and signing • Critical settings are interfaced by the generic applications: • Trim Editor • Settings Copy • Settings Generation • Settings Acquire • …all these tools are critical settings aware (RBAC login and Role Picker)

9. MCS in LHC controls • MCS is part of FESA: • Critical properties get an additional field called „signature” • Holds signature for the rest of the fields • Message digest of all the remaining fields signed with critical role’s private key • Signature field has to be correctly filled by client’s application (LSA) • Signature field is verified just after the message is received from the client, but before the front-end server action gets executed • If Signature is not valid, the set method is rejected with an exception • Only data with the valid signature are accepted for critical properties • RBAC services for MCS: • Provides secure keystore for private-public key pairs for critical roles • Secure signing service • Role picker recognizes and treats differently critical roles

10. LSA Trim Editor with Critical Settings

11. How do we make settings critical? (1) • Must be LSA setting • Define LSA parameters for concerned FESA properties • RBAC critical role must be defined and associated with the critical property • One must have the critical property administrator RBAC role • LHC Protection Panel • LSA is the master datasource for MCS • property is marked as critical only in LSA database • Set property as critical using LSA Parameter Configuration application

12. How do we make settings critical? (2) • Use LSA ParameterConfigurationapplication (already RBAC & MCS aware)

13. How do we make settings critical? (3) • Generate new FESA xml configuration file and sent it via email to equipment owner • Configuration file needs to be put on the FESA device – requires restart of server

14. How to ensure that DB and HW properties are in synch? (1) • Integrity checks in MCS: • Integrity in the LSA DB (db check) • LSA is the true source, make sure db signature is consistent with the data • Integrity between LSA DB and HW (online check) • Signature is not kept on the front-end, compare current values in DB & HW • Will be done before every fill and during the fill (SIS, Sequencer) • Check deployed config - if configuration file is gone…we know it as well… • Verify whether the configuration file for critical settings is on the front-end • Verify whether the configuration file has the correct contents • All the checks are provided in the Parameter Configuration application • In the form of GUI buttons • Can be launched asynchronously, independently of Sequencer & SIS

15. How to ensure that DB and HW properties are in synch? (2)

16. Features of dealing with Critical Settings • Higher level parameters • Designers of parameter spaces have to be aware that high level parameters (e.g. Momentum) become implicitely critical if they depend on lower-level critical parameters • If collimators tolerance function depends on Momentum and was made critical then only collimators expert can trim value of Momentum !!! • Generation of critical settings • Whenever a cycle has to be generated: need for an authorized person • Issue for optics/energy dependent critical settings (multiplexed): e.g. Collimators • Most of all critical settings arenon-multiplexed • Copy of critical settings • Whenever settings have to be copied from one cycle to another one: • Critical settings are skipped (cycle copy) • Only authorized person can copy critical settings (beam process copy) • Issue again for optics/energy dependent critical settings: e.g. Collimators

17. Conclusions • RBAC and MCS • provide infrastructure for operating the LHC safely • are fully integrated in the LHC control system • are based on industrial security standards • Using MCS we can always ensure integrity of settings which are crucial for machine safety • Clearly, RBAC and MCS will require a cultural change… • …but this infrastructure is as transparent to normal operation as possible • Authentication by Location • Single Sign On • Only a few critical settings – critical settings must be exceptional • RBAC and MCS are already operational