# Presentation: 924095

## Role Based Access Control for CERN’s AB/CO

- Motivation
- Organization
- Requirements & High Level Design
- Test Results
- Deployment

- Suzanne Gysin

## LHC Energy

- The energy of an AirBus A380 at 700km/hr corresponds to the energy stored in the LHC magnet system*

- *Rüdiger Schmidt MAC 9 December 2005

- **Mike Harrison HCP2006

- LHC Beam Energy = 350 MJ
- Kinetic Energy
- 1 small aircraft carrier of 104 tons going 30 kph
- 450 automobiles of 2 tons going 100 kph**
- Chemical Energy**
- 80 kg of TNT
- Thermal Energy**
- melt 500 kg of copper
- raise 1 cubic meter of water 85 C: “a ton of tea”

## Tevatron Incident Example

- LHC Energy
- 7 Tev = 7 * Tevatron
- 27 km = 4 * Tevatron
- 8.3 T field = 2 * Tevatron
- LHC Luminosity
- 1034 = 60 * Tevatron
- LHC Beam Power
**350 MJ = 250 * Tevatron**
- Tevatron Run II example:
**Roman Pot re-inserts itself while set to move out**
**Scraped halo leads to quench of 16 magnets**
**3 mm orbit change**
**Hole drilled in primary collimator**
**Hit an damaged secondary collimator**
**Beam abort from quenches**
**BLM’s by-passed to allow ramping**

- primary collimator

- secondary collimator

## SPS experiment: Beam damage at 450 GeV 

- Controlled SPS experiment
- 81012  protons clear damage
- beam size σx/y = 1.1mm/0.6mm
- above damage limit
- 21012  protons
- below damage limit

- 6 cm

- 25 cm

- 0.1 % of the full LHC beams

- V.Kain et al

**Notes:**
Um die Voraussagen einer Simulation zu testen, wurde der SPS Strahl auf ein 25 cm langes Metalltarget gelenkt. Wie man auf dem Bild sieht,, wird der hintere Teil des Targets zerstoert (durch die Schauerentwicklung).

Die Energie des Strahls ensprach 0.1 %  der Energie des LHC Stahls, bei nominalen Parameters

## 
Paul Collier AB/CO LHC Workshop January, 2005 :
Some 500 objects are capable of moving into the aperture of either the LHC Ring, or the transfer lines 
Ranging from passive valves up to very complex experimental detectors

Rüdiger Schmidt:
http://rudi.home.cern.ch/rudi/docs/VisitLHCWuppertal2006.ppt
The complexity of the accelerator is unprecedented and repair of damaged equipment would take long, for example, the exchange of a superconducting magnet takes about 30 days

- Paul Collier AB/CO LHC Workshop January, 2005 :
- Some **500 objects are capable of moving into the aperture** of either the LHC Ring, or the transfer lines
- Ranging from passive valves up to very complex experimental detectors
- Rüdiger Schmidt:
- _[http://rudi.home.cern.ch/rudi/docs/VisitLHCWuppertal2006.ppt](http://rudi.home.cern.ch/rudi/docs/VisitLHCWuppertal2006.ppt)_
- The complexity of the accelerator is unprecedented and repair of damaged equipment would take long, for example, **the exchange of a superconducting magnet takes about 30 days**

- In the LHC:

## Motivation: Machine Safety

- The energy stored in the LHC magnets and beam is enormous.
- The potential for crippling machine damage is a serious concern
- CERN has developed a multi-pronged approach for machine safety
- Hardware Protection
- LHC Beam Interlock System
- Powering Interlock System
- Software Interlock system
- Role Based Access
- Prevents unauthorized access to settings
- Provides logging to detect errant settings
- Is of critical importance to other superconducting colliders (Tevatron, RHIC)

## Back to Role Based Access Control 

- RBAC is software to prevent:
- A well meaning person from doing the wrong thing at the wrong time.
- An ignorant person from doing anything, anytime.
- Prevention means, you will see an error dialog. They are annoying but,  you’ll press OK and the world moves on without any consequences.
- On the other hand, you could trigger the Machine Protection System  ...

## Machine Protection Systems and (HW) Interfaces

**LHC**
**Beam**
**Interlock **
**System**

- Access Safety
- System

- Beam Dump
- Trigger

- SPS Extraction
- Interlocks

- Injection
- Kickers

- essential
- circuits

- auxiliary
- circuits

- TL collimators

## Or shop for some new magnets 

## RBAC Motivation 2 - Stability

- Once the machine settings are fine tuned for maximizing luminosity and operational stability...
- ...access is denied during certain machine states

## RBAC Motivation 3 - Logging

- Setting logger:
- RBAC logs the date and time, application, user name, for each protected setting
- Very valuable for “post mortem” examinations and for software and hardware commissioning
- Can help finding errors like ‘sequencer typo’ during commissioning
- Will store all Trim/Drive protected settings

## Motivation Summary

- Machine Safety
- Energy stored in the LHC is enormous
- RBAC protects from crippling machine damage
- RBAC prevents invoking machine protection system
- Machine Performance
- Don’t mess with a fine tuned system
- Settings logger
- Hardware and Software commissioning

## Role Based Access Control for CERN’s AB/CO

- Requirements and High Level Design
- Team organization

- Suzanne Gysin

## Role Based Access Control (RBAC)

- What is a ROLE?
- A role is a job function within an organization.Examples: LHC Operator, SPS Operator, RF Expert, BPM Developer ...
- Roles are defined by the instrument designers in a security policy.
- A user may have several roles
- What is being ACCESSED?
- CMW devices which map to physical devices (power converters, collimators, kickers, etc.)
- What TYPE of access?
- get: the value of a property once
- monitor: the property continuously
- set: the value of a property

## Requirements

- RBAC is software to prevent
- An ignorant person from doing anything, anytime.
- Authentication = A1
- Validating the identity of the user
- A well meaning person from doing the wrong thing at the wrong time.
- Authorization (or authorisation) = A2
- Verifying that a known person has the authority to perform a certain operation.

## Authentication Requirements

- People using controls software outside the CCC will be asked to log in.
- NICE or Certificates:
- The user will be able to use the NICE user name and pw or a CERN certificate.
- No login is needed in the CCC:
- when logging in at a CCC console with the dedicated group login and password, the applications will start up without further login. (Authentication by location)
- Log in is required for Critical Applications even in the CCC:
- for a small number of applications designated as critical, the operator in the CCC shall be required to provide personal credentials in addition to the generic login.
- Timeout for applications:
-  there shall be a timeout to prevent accidental use, and to keep the integrity of the authentication.

## Authorization Requirements

- RBAC shall be used for granting access to get, monitor, and set devices.
- Logging and tracking
- Log the date, time, application, location, role, username for all protected settings.
- Temporary permission
- Engineer in charge can grant someone temporary permission
- GUI for managing roles, rules, locations, and applications
- The parameters to define acess are:
- Role
- Location
- Machine mode
- Application

## Design for Roles, Locations, Modes

| Role | User |
| --- | --- |
| LHC-Operator | LAMONT |
| LHC-Operator | VKAIN |
| LHC-EIC | LAMONT |
| BT-Expert | CARLIER |
| BT-Expert | VERHAGEN |
| BT-Expert | TMUELLER |

| Location | hostname |
| --- | --- |
| CCC-LHC | T.B.D. |
| BT-RT | cerntsab04 |
| BI-RT | cerntsab01 |
| BT-UA23 | cwe-ua23-pc1 |

- Role maps to a group of users which assume this role. This mapping is not unique
- Location maps to a group of hosts. This mapping is unique. It is made to avoid rule definition for each host.
- Machine Mode (mode group) is a universally agreed state of the machine. It will be defined by the operation, and is not specific to RBAC.

| Operation Mode |
| --- |
| OPERATION |
| SHUTDOWN |
| NO-OPERATION |
| BEAM |
| NO-BEAM |

## Access Rule Examples

- LHC operator to set BPM Settings from CCC-LHC island only, using any application, at anytime
- CLASSNAME:BPMLHC
- PROPERTY:SETTING
- ROLE: LHC-OPERATOR
- APPLICATION:
- LOCATION: CCC-LHC
- MODE:
- ACCESS: set
- BI-Expert to set any kicker property during shutdown:
- CLASSNAME: LhcMKIkick
- PROPERTY:
- ROLE: BT-Developer
- APPLICATION:
- LOCATION:
- MODE: SHUTDOWN
- ACCESS: set

## High Level Design

- A1:
- User requests to be authenticated.
- RBAC authenticates user via NICE user name and password or CERN certificate
- RBA returns token to Application
- A2:
- Application sends token to CMW when connecting.
- CMW/FE verifies token signature once, and uses the credentials for every subsequent request
- CMW checks access map for role, location, application, mode

- 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

## Token and Access Maps

- RBAC Token:
- Proof of authentication
- Holds information for authorization: roles, location, application
- Digital signature
- Access map
- Access maps are text files on the front ends
- They are built from the database table holding all access rules
- Contain the subset of access rules for a specific server on the front end
- Read into memory for fast permission checks

## Requirements and High level design Summary

- RBAC is software to prevent
- An ignorant person from doing anything, anytime.
- Login using NICE user name and password.
- No login required in CCC, critical applications being the exception
- Timeouts
- A well meaning person from doing the wrong thing at the wrong time.
- Access is determined by: role, location, mode, and application
- Logging

## Participation in Requirements and Design

**Requirements:**
***Prepared by:***
**S. Gysin FNAL/ LAFS**
**K. Kostro AB/CO**
**G. Kruk AB/CO**
**M. Lamont AB/OP**
**S. Lueders IT/CO**
**W. Sliwinski AB/CO**
**P. Charrue AB/CO**
***Checked by:***
**J. Wenninger AB/OP**
**S. Page AB/PO**
**E. Hatziangeli AB/CO**
**V. Kain AB/OP**
**K. Hanke AB/OP**
**R. Schmidt AB/CO**
**R. Steerenberg AB/OP**
***Approved by:***
**P. Collier AB/OP**
**H. Schmickler AB/CO**
**R. Bailey AB/OP**
**S. Myers AB**

**Design:**
***Prepared by:***
**P. Charrue AB/CO**
**V. Baggiolini AB/CO**
**W. Gajewski AB/CO**
**S. Gysin FNAL/ LAFS**
**V.Kain AB/OP**
**K. Kostro AB/CO**
**G. Kruk AB/CO**
**R. Gorbanosov AB/CO**
**S. Page AB/PO**
**A. Petrov FNAL/LAFS**
**W. Sliwinski AB/CO**
**N. Stapley AB/CO**

**Design:**
***Checked by:***
**E. Hatziangeli AB/CO**
**K. Hanke AB/OP**
**M. Lamont AB/OP**
**S. Lueders IT/CO**** **
**R. Schmidt AB/CO**
**R. Steerenberg AB/OP**
**J. Wenninger AB/OP**
***Approved by:***
**P. Collier AB/OP**
**H. Schmickler AB/CO**
**R. Bailey AB/OP**
**S. Myers AB**

## RBAC Organization

- RBAC team leader (S. Gysin - FNAL- LAFS) reports directly to AB-CO-IN section leader (P. Charrue)
- Development:
- Authorization – K. Kostro AB-CO
- CMW - W. Gajewski AB-CO
- RBAC server - S. Gysin FNAL-LAFS
- Authentication – A. Petrov FNAL-LAFS
- Database – M. Peryt AB-CO
- LSA – G. Kruk AB-CO
- JAPC – R. Gorbonosov AB-OP

## Documents and Meetings

- EDH approved requirement document
- EDH in review design document
- Vertical Slice Test Jan. 18th
- Formal review by CERN Feb. 16th
- Weekly meeting
- Participate in CNIC
- Source code in CVS package: accsoft-security-rba
- All information is on RBAC wiki:
- _[http://controls-wiki.web.cern.ch/controls-wiki/COGroup/RBA/RoleBasedAccess](http://controls-wiki.web.cern.ch/controls-wiki/COGroup/RBA/RoleBasedAccess)_

## RBAC Vertical Slice Test Report

- Suzanne Gysin 1-21-07

## Vertical Slice Test 

- Date: January 18 -19 2007
- Goals:
- Verify the design concepts for basic RBAC authentication and authorization
- Measure overhead for authentication, verifying token, reading access map for permissions.

## Proof of Concepts/Vertical Slice Test

- A1
- Application to request an RBA token
- RBA authenticates user via NICE user name and password
- RBA returns token to Application
- A2:
- Application sends token to CMW when connecting.
- CMW/FE verifies token signature once, and uses the credentials for every subsequent request
- CMW checks RBA access map

- EquipMonitor
- GUI

- RBAC

**RBA 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

## 17 Tests 

- ~ 30 new classes in CVS for RBAC, new code in CMW, JAPC Change, and EquipState change.
**Authentication Tests:**
- Valid user name and password, location not in database
- Valid user name and password, location in database
- Multiple Roles
- No Roles
- Invalid NICE username
- Invalid NICE password:
- CANCEL login dialog

## Authorization tests

**Authorization:**
- EquipState sends a request to read an unprotected device
- EquipState requests a write on an unprotected device
- EquipState requests to set a protected device with valid role, and request is granted
- EquipState requests a write on a protected device, multiple roles, one role is valid, and request is granted
- EquipState requests a write on a protected device from an invalid location, and request is rejected
- EquipState requests a write on a protected device with illegal role, and request is rejected
- EquipState requests to read a protected device, and request is rejected
- EquipState requests to read a protected device from an invalid location
- EquipState requests to read a protected device with the correct role
- EquipState requests to read a protected device that has no location specified

## Results

**All tests passed**
**Timing Authentication: **
- LINUX
- *** AUTHENTICATION TIME: 1496 ms.
- *** AUTHENTICATION TIME: 965 ms.
- *** AUTHENTICATION TIME: 864 ms.
- *** AUTHENTICATION TIME: 1047 ms.
- *** AUTHENTICATION TIME: 830 ms.
- *** AUTHENTICATION TIME: 763 ms.
**994 ms****	****average**

- Windows:
- *** AUTHENTICATION TIME: 1203 ms.
- *** AUTHENTICATION TIME: 1281 ms.
- *** AUTHENTICATION TIME: 750 ms.
- *** AUTHENTICATION TIME: 937 ms.
- *** AUTHENTICATION TIME: 1219 ms.
- *** AUTHENTICATION TIME: 703 ms.
- *** AUTHENTICATION TIME: 734 ms.
- *** AUTHENTICATION TIME: 953 ms.
**973 ms****	****average**

## Authorization Timing

- The distribution over 97 operations of authorization times:
- < 1ms : 20
- < 2ms : 38
- < 3ms : 31
- < 4ms : 8
-  > 4ms : 0
- With the median 1<m<2 ms and the average = 2.2ms.
**RBAC adds between 0.5 and 1% to the tested command**

- For the token verification, we had 48 such actions.
- Out of which:
- < 1ms : 0
- < 2ms : 28
- < 3ms : 18
- < 4ms : 2
-  > 4ms : 0
- Median 1<m<2 ms and the average = 2.33ms.
- Total EquipState command operation:
- average FALSE 651 ms
- average TRUE 467 ms
- average READ 621 ms
- average WRITE  102 ms
- average total 588 ms

## Test Summary

- So far so good, we progress to the production release.
- Keep measuring the authorization times map and token verification time 2.2 ms for verifying the access map

## Role Based Access Control for CERN’s AB/CO

- Deployment, support, impact on personnel

## Deployment Plan

**March 07**
**Discussion with AB Equipment groups**
**Integration plan**
**April 07**
**Deploy production quality Authentication server**
**Java API for token access**
**GUI for A1 DB management (Roles, Apps)**
**Users: HW commissioning sequencer**
**Tutorials on how the API works **
**Prior to June 2007:**** ****Operate with and without RBAC**
**Requests without tokens are honored for all properties.**
**Requests with tokens are honored for all properties, and are validated against access maps.**

## Deployment Plan

**After June 2007: RBAC for restricted properties**
**Requests without tokens are honored and have access to all unrestricted properties.**
**Requests without tokens are not honored for properties protected in the access maps.**
**RBAC will provide a C++ API to obtain a token for C++ clients for A1**
**For other languages we will examine them on a case by case basis**
**Deploy two redundant RBAC servers**
**Next step (date to be determined and to be approved by the Equipment Groups and by Operation, possibilities LHC startup, or March ‘08) **
**Requests without tokens are no longer honored for some categories of operations (to be specified, e.g. all set operations for LHC).**

## Support

**Software :**
- RBAC core: A. Petrov, S. Gysin
- Database: M. Peryt
- JAPC: R. Gorbonosov
- CMW: K. Kostro, W. Gajewski
**Operations :**
- RBAC servers: AB/CO/IN
- RBAC call list: P.Charrue

## Resources

- RBAC CORE development :
- RBAC server, CMW, JAPC
- 4 more months at ~ 3 FTE
-  (1.5 FNAL, 1.5 CERN)
- LSA + other apps :
- Applications to include authentication
- Implement the timeout support
- A few days per application
- Other languages support :
- e.g. LabVIEW, PVSS, VB, non-CMW communication
- Case by case study

## Resources

- Operations after deployment
- Operators and Equipment groups must populate Roles and Access Maps
- Software experts must include:
- A1
- A2 if they do not use CMW
- Timeout management

## Impact on Personnel

- Definition of the Security Policy
- Operators, Equipment Groups, Management
- Design access maps, list critical applications
- Equipment Groups, Operations Groups
- Include RBAC in the software chain
- Application, Equipment servers
- RBAC Maintenance:
- RBAC servers and RBAC core
- RBAC Roles-Users database
- Scrub against HR users

## Change in work environment:

- Operations
- Authentication
- Log in outside of CCC
- Log in for critical applications inside CCC
- Manage roles and rules
- RBAC Boss go/no go for access maps
- Equipment Groups
- Revise expert apps to authenticate
- Manage roles and rules
- Authenticate
- Software developers
- Include A1 in the GUI and A2 in the server

## Deployment Summary

- RBAC core will be operational in June 07
- Impact of RBAC is small in terms of effort...
- ...but will incur big changes in the working habits

## RBAC Summary 

- RBAC is software to prevent
- An ignorant person from doing anything, anytime.
- A well meaning person from doing the wrong thing at the wrong time.
- Motivation:
- Machine Safety
- Machine Stability
- Settings Logging
- Phased Deployment plan:
- Authentication – end of April
- Authorization - End of June
- Resources:
- Development: 4 months 1.5 FNAL FTEs

## Andrey Petrov

## Role Based Access Control for CERN’s AB/CO

- Authentication

- Andrey Petrov

## Authentication

- Prevent an ignorant person from doing anything, anytime.
- Login using NICE user name and password.
- No login required in CCC, critical applications being the exception
- Timeouts

## RBAC A1

- RBAC Server

- RBAC DB

**RBAC Token:**
- Application name
- User name
- IP address/location
- Time of authentication
- Roles[ ]
- Digital signature (RBA private key)

- NICE

- 1

- 2

- 3

- 4

- 5

- 6

- (optional) The client sends the application name to the server.
- (optional) If the application is not critical and the location is in CCC, server issues a token.
-  If the location is outside the CCC or it is a critical application the client pops up a login dialog.
- The user enters the name and password OR certificate location and password OR clicks "Cancel".
- The client sends the server the application name, and provided credentials (if any). The user name and password are sent inside an HTTP request, the certificate is transferred be means of the regular SSL protocol handshake.
- The server checks the application name, the location, and user's credentials (if any), and issues a token if this information is sufficient to identify the user.

- 6

- RBAC Client

## RBAC Client and Server

- RBAC Client:
- Login Dialog
- SSL communication with server
- RBAToken class and access methods (getRoles, getUser, getLocation etc)
- Error handling
- Single Sign On (SSO)
- Uses a master token and derived tokens
- RBAC Server
- Database connection management
- NICE web service (Standard provided by CERN IT)
- Certificate authentication
- Cryptography
- Digital signature
- Key generation and management
- Token Factory
- Jetty, Java, SSL

## RBAC Token

- RBAToken[serial=0xa37e0303;
- auth=2007-02-13T11:06:36;
- end=2007-02-14T11:06:36;
- application=AppPrincipal
- [name=SimpleRBATest;
- critical=false;
- timeout=360];
- location=LocationPrincipal[
- name=DEFAULT;
- address=/128.141.72.161;
- auth-reqd=true];
- user=UserPrincipal[name=
- sgysin;
- roles=[LHC-Operator,RBA-Developer]]]

- Token definition in CORBA IDL
- Generate JAVA classes
- Generate C++ classes
- Serialization and interoperability

**RBAC Token:**
- Application name
- User name
- IP address/location
- Time of authentication
- Roles[ ]
- Digital signature (RBA private key)

## Digital Signature/Asymmetric Encryption

- RBAC has a secret private key
- ‘Signing the token’ means encrypting the checksum of the token contents with the private key
- RBAC has a public key to decrypt the token signature
- Distributed to anyone
- Used to decrypt what was encrypted with the private key (in this case the token signature)
- If the token is verified with the public key, it proves
- the origin: since it was encrypted with RBAC’s private key and only the RBAC server has it
- the integrity: the contents have not changed since it has been signed.

## Cryptography in RBAC

- _RBAC Server Keys_	*512-bit RSA with a self-signed certificate*
- Signing RBA tokens
- Server-side SSL authentication
- _Users' X.509 certificates - optional_
- Authenticating the users in RBAC, implemented via client-side SSL authentication

- gysin@fnal.gov

- 02-16-07

## Key Deployment

- _On the server (in a protected directory):_
- RBA private key (+certificate)	*JKS keystore*
- Trusted Certificate Authorities	*JKS keystore** *
- _Distributed along with the code:_
- RBA public key**s** (+certificates)	*JKS keystore** *
- _On the client (optional):_
- User's certificate	 		 *PKCS#12 or JKS*

- gysin@fnal.gov

- 02-16-07

## Key Deployment Diagram

- gysin@fnal.gov

- 02-16-07

## Role Based Access Control for CERN’s AB/CO

- Data Management

- Maciej Peryt

## TOC

- Data Model aspect

- GUI demo

## Role Management

## Access Rules Management

## Applications, Locations, Machine Modes, Certificates

## GUI

- Oracle ADF
- J2EE Application Framework
- Technology selected by AB/CO/DM
- GUI Status
- Early incomplete prototype
- Rapid development cycle

## Slide 60

## Slide 61

## Slide 62

## Slide 63

## Slide 64