1 / 17

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

LSA & Safety – Integration of RBAC and MCS in the LHC control system. RBAC – Controlling Access. What is being accessed ? D evice properties ( P ower C onverters , C ollimators , K ickers , etc.) What type of access ? get : the value of a property once

ronniehood
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related