W. Sliwinski – eLTC – 7March08 1 LSA & Safety – Integration of RBAC and MCS in the LHC control system.

W. Sliwinski – eLTC – 7March08 1

LSA & Safety –Integration of RBAC and MCS

in the LHC control system

RBAC – Controlling Access

• What is being accessed ?– Device properties (Power Converters, Collimators, Kickers, etc.)

• What type of 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:

1. How to create and manage a role

2. How to create and manage rules (permissions)

3. How to load the rules (Access Maps) into the CMW servers

W.Sliwinski – eLTC – 7March08 2

RBAC Overview

W.Sliwinski – eLTC – 7March08 3

Application RBAC

RBAC Token:

•Application name

•User name

•IP address/location

•Time of authentication

•Time of expiry

•Roles[ ]

•Digital signature (RBA private key)

CMW client

FESA

CMW server

Access MAP

T

T

T

Application Server

Configuration DB

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

– CMW client sends token to CMW server

– CMW server (on front-end) verifies token

– CMW server checks Access Map for role, location, application, mode

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

– Verify Token’s digital signature with RBAC public key

• Token came from the RBAC server

• Token contents have not been altered

– Check the expiration time

W.Sliwinski – eLTC – 7March08 4

W.Sliwinski – eLTC – 7March08 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

W.Sliwinski – eLTC – 7March08 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…

W.Sliwinski – eLTC – 7March08 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 picking a specific role if user has multiple ones

• Dealing with critical settings

– Generation and management of 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 critical role can be selected when trimming critical settings

W.Sliwinski – eLTC – 7March08 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)

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

W.Sliwinski – eLTC – 7March08 9

W.Sliwinski – eLTC – 7March08 10

LSA Trim Editor with Critical Settings

W.Sliwinski – eLTC – 7March08 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

• Use LSA Parameter Configuration application (already RBAC & MCS aware)

How do we make settings critical? (2)

W.Sliwinski – eLTC – 7March08 12

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

W.Sliwinski – eLTC – 7March08 13

W.Sliwinski – eLTC – 7March08 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

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

W.Sliwinski – eLTC – 7March08 15

W.Sliwinski – eLTC – 7March08 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 are non-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

W.Sliwinski – eLTC – 7March08 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