Authentication and Authorization for the ESS* Control System

Authentication and Authorization for the ESS* Control System

Suzanne Gysin – European Spallation SourceJaka Bobnar – Cosylab2013-10-06

*ESS: European Spallation Source

What is ESS?• The European Spallation Source

(ESS) will house the most powerful proton linac ever built.– The average beam power will be 5

MW which is five times greater than SNS.

– The peak beam power will be 125 MW which is over seven times greater than SNS

10/05/2013Suzanne Gysin, RBAC for ESS Control

System

Neutron radiograph

X-Ray Image

ESS is a neutron spallation source for neutron scattering measurements.

Neutron scattering offers a complementary view of matter in comparison to other probes such as x-rays from synchrotron light sources.

The scattering cross section of many elements can be much larger for neutrons than for photons.

ESS Science Case


System

Where Will ESS Be Built?• ESS is located in southern

Sweden adjacent to MAX-IV (A 4th generation light source)

• To provide a world-class material research center for Europe


System

How Much Will ESS Cost?Personnel Investment


System

How Will ESS be Funded?

with in-kind and cash contributions.


System

How Long Will ESS Take to Build?


System

Control System Core Software - requirements

• Configuration Data Management– Lattice DB*– Controls Configuration DB*– Device Configuration DB– Cable DB*

• Requirements documents available• In collaboration with DISCS


System

• Control System Services– Authentication and Authorization– CSS including BOY, BEAST, and BEAUTY– Save, Compare and Restore*– Post Mortem support – Maintenance Log – Diagnostic Logging Service

• Naming Convention– Database, tools, and procedures


System

Control System Core Software - requirements

Software Core Milestones

• 2014:Q2: MS 1: Lattice Database V2 (BLED 2)Q3: MS 2: Naming convention software tools

• 2015: Q1: MS 3: Controls Configuration Database MS 4: Cabling Database• 2016: Q2: MS 5:Device Configuration Database• 2017: Q1: MS 6: Vertical Test Complete


System

Authentication and Authorization (RBAC)

• 2006-7 – implemented RBAC for LSA the LHC Control system at CERN.

• Proposal/Investigation to:– Adapt RBAC to EPICS– Adapt RBAC to general resources


System

Role Based Access Control (RBAC)

1.Machine Safety– ESS’s 5 MW is powerful and

potentially very damaging– RBAC protects from crippling

machine damage– RBAC is proactive rather than

reactive, it prevents invoking machine protection system

2.Machine Performance– Don’t mess with a fine tuned

system– Access is denied during

certain machine states

10/05/2013 Suzanne Gysin, RBAC for ESS Control System

CERN’s LHC Controls RBAC extended

1.LHC RBAC has good qualifications– in use on a complex control

system, with many diverse users, for many years.

2.EPICS is– popular choice for new

control system project– could use a standard RBAC

service3.ESS controls

– Uses EPICS– Needs an RBAC implantation


Two main questions …

1. How to extend CERN’s LHC controls RBAC to EPICS?

2. How to extend CERN’s LHC controls RBAC to protect general resources such as databases and software services?


System

RBAC at LHC Controls at CERNAuthentication of the user:

– User sends a request from the Application to be authenticated by the RBAC server

– RBAC authenticates user via NICE user name and password

– RBA returns RBAC token to Application

Authorization of a request:– 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


ApplicationRBACServer

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

Two use cases

– Use case 1: RBAC for EPICS• protect access to the Channel Access Process Variables

– Use case 2: RBAC for Configuration Data• Configuration database and its Java web applications


System

Use Case 1: RBAC for EPICS• Karl wants to protect the

klystrons.• Karl creates a role “Klystron

Commissioner” with write privileges

• “Klystron Crawler” is a Channel Access Client application to monitor and control the Channel Access PV’s.

• “Klystron Controller” is a Channel Access Server for the klystron PV’s.


System

Use Case 1: RBAC for EPICS• Players:

– Karl – the user– Klystron Commissioner– the role– Klystron Crawler– the application - Channel Access Client – Klystron Controller – the IOC with the relevant PV - Channel Access

Server

• Actions:1. User Authentication

• Check user name and password

2. Authorization of a session• Check token timeout and signature

3. Authorization of a request• Check token role, host id, and system parameters


System

RBAC for EPICS:Authentication of the user

1. User logs into the CA Client with the login dialog provide by the RBAC service.

2. If the authentication is not successful, the RBAC servers returns an error and the CA Client denies access to the User

3. If the authentication is successful , the CA Client receives a token with the following:– Role (Klystron Commissioner)– Location (the host id)– RBAC server digital signature encrypted with the RBAC’s private key

(512 bits 64 bytes)

4. User Authentication is complete


System

Goal: to check token parameters common to all requests only once.

– check the RBAC signature with the public key– check the expiration date of the token

1.The CA Client connects to a CA Server via the CA handshake to establish a session.2.CA Client sends token information (role, location, and signature) to the CA Server in the header. *3.CA Server verifies the token’s expiration date and signature with RBAC public key.*


System

RBAC for EPICS:Authorization of the session

4. If invalid, the session is terminated and the user notified with an error.

5. If the token is valid, the CA Server saves the token for authorizing future requests within this session.

6. The user is authorized for the session


System

RBAC for EPICS:Authorization of the session

Authorization of the session issue

• Requires a change in Channel Access Protocol for starting a session (i.e. sending the token information)

• Requires the implementation of checks in the existing Channel Access Servers

• Distribution of public key to the CA serversWork around … • Make the session authorization optional


System

RBAC for EPICS: Authorization of a request

1. The user initiates a request to set a PV using the CA Client.

2. CA Client sends the request to CA Server along with the role and host id.

3. CA Server checks the role, location, beam mode or other system parameters as defined in the .afc file

4. If the authorization fails, CA Server returns an error, If the authorization succeeds, CA Server fulfills request


System

RBAC for EPICS: Logout

1. User logs out by calling the RBAC logout API with the session

2. Session is terminated all token information is removed from the CA server


System

RBAC for EPICS: Issues1. Time it takes to verify the token on the first handshake.

• Do we want to factor out the handshake or include it in the first PV access?

• Prototype the time it takes to verify token.2. The handshake for starting a session is modified

• A login and logout interface specific for Channel Access clients that manages the session with a modified handshake.

• Make the session authorization optional3. Users may have multiple roles, how to select and switch roles?

• How common is this, and what is the use case?4. Channel Access uses the OS user name, RBAC expects the role name in

the request. – How is the user name changed to the role in the CA Client?


System

Use Case 2: RBAC for Configuration Data

• Karl, still the RF engineer, would like to protect his klystron configuration.

• The role“Klystron Commissioner” has permission to change the RF configuration.

• The “Configuration Manager” is the app used to edit the configuration.

• The Configuration Manager’s underlying database is the Controls Configuration Database (CCDB).


System

• Players:– Karl – the user– Klystron Commissioner– the role– Configuration Manager– the application – Glassfish web application– Controls Configuration Database – the RDB, the resource to protect

• Actions:1. User Authentication

• Check user name and password

2. Authorization of a session• Check token timeout and signature

3. Authorization of a request• Check token role, host id, and system parameters


System

Use Case 2: RBAC for Configuration Data

RBAC for configuration data: Authentication of the user

1. The user logs into the Configuration Manager using the login dialog provide by the RBAC service.

2. If the authentication is not successful, the Configuration Manager denies access

3. If the authentication is successful, the Configuration Manager receives a token with the following:– Role (Klystron Commissioner)– Location (the host id)– RBAC server digital signature encrypted with the RBAC’s private key

(512 bits 64 bytes)

4. User Authentication is complete


System

1. The Configuration Manager ( the app) verifies the tokens expiration date and signature with RBAC public key.*

2. If invalid, the session is terminated and the user notified with an error.

3. If the token is valid, the Configuration Manager saves the token for authorizing future requests within this session.


System

RBAC for configuration data: Authorization of the session

RBAC for configuration data: Authorization of a request

1. The user initiates a request to set a database field using the Configuration Manager

2. Configuration Manager uses the database service (API) to interact with the database.

3. The Configuration Manager sends the role, and location along with the request to the database service.

4. This database service checks the role, location, and beam mode according to its access map for the specific request.*

5. If the authorization fails, Configuration Manager returns an error, if it succeeds the request is full filled.


System

RBAC for configuration data: Assumptions

• The Configuration Manager checks if the token has expired every n-minutes and prompts the user for a renewal.

• The Configuration Manager uses a database service, the database service is the only way to connect to the database.

• The Configuration Manager has the RBAC public key• The access rights are written by the owner of the database

and the algorithm to check the access rights is local to the database API.

• The Configuration Manager saves the token for the duration of a session.


System

RBAC for configuration data: Issues

1. If there is a use case for queuing or forwarding requests it needs to be well understood

2. No standard access map: Each database service will have to implement its own request authorization code and access map.

3. Should the session authorization be in the application or the database service?

4. How does the configuration database receive the beam mode ?


System

Commonalities, LHC, EPICS, Databases

• Authentication– RBAC server authenticates the user

• protocol differs, CERN uses RBAC token, ESS may use Kerberos

– RBAC server is responsible for logging authentication requests

• Authorization– RBAC server manages the mapping of users, roles, and permissions for

the roles– RBAC server generates the access rules for a the device server and

makes them available• Access rights syntax differs: RBAC uses table, ESS uses EPICS access

control file syntax• Databases have their own syntax which is not managed by RBAC


System

Conclusion• ESS is collaborating with DISCS to extend CERN’s LHC controls

RBAC for EPICS and other software resources.• We have shown two use cases using the same steps and with

the same general architecture. From this we can decide – which parts are re-usable– which parts to implement first

• Next steps:– Gather use cases and requirements from ESS and DISCS collaboration– Prototype and design– Ready for development, 2014-Q1


System

Authentication and Authorization for the ESS* Control System

Documents

Transcript of Authentication and Authorization for the ESS* Control System