1. Suzanne Gysin 1, Andrey D. Petrov 1, Pierre Charrue 2, Wojciech Gajewski 2, Kris Kostro 2, Maciej Peryt 2 1 Fermi National Accelerator Laboratory, 2 European Organization for Nuclear Research Role-Based Access Control for LHC Devices ICALEPCS’07 TPPA04 Specify roles that can access a Controls Middleware device properties Device classes rules are created by a Rule-Maker Rules are managed by the device class administrator Role = job function Roles are create by a Role -Maker Role membership is managed by Role-Administrator Implementation: Give People Roles = Authentication = A1 Give Roles Permissions = Authorization = A2 Roles Permissions Roles Permissions (Access Rules) USERS DEVICE PROPERIES ROLES Special Features: Authentication by Location: an access rule can limit the access on a location basis. Locations are set in the database on a host address basis. Authentication via X.509 certificates. Authorization by application: an access rule can limit the access for applications. Role Picker: a user may pick a specific role if multiple roles are available. Generate and manage public and private keys for Critical Settings. Token Log (currently over 140,000), keep track of who receives tokens and if they were rejected. Load balancing (2 RBAC servers). Web interface for role) Single Sign-on: once logged into one application, the others pick up the token. Temporary (EIC) roles. Deployment The RBAC server is deployed as a Java web application The RBAC Authentication client is deployed as a jar file (Java) C++ RBAC Authentication client library C++ RBAC Authorization Middleware library Motivation 1.Machine Safety Energy stored in the LHC is enormous Protects from crippling machine damage Prevents invoking machine protection system 2. Machine Performance Don’t mess with a fine tuned system. Permissions according to Machine mode 3.Commissioning feedback All protected settings are logged Hardware an d Software commissioning Debugging Requirements: Documented and well defined in a formal Requirements document Well contained (no requirements creeping) Formal approval process Authenticated users receive a token Token contains roles and user credentials Digital signature Contains all rules for one front-end Map is read into memory on start up Dynamics: 1.Access Map is read into front-end 2.The user authenticates and receives an RBAC Token 3.The token is passed in the settings request to the Controls Middleware 4.The Controls Middleware server, on the front end, verifies the token and checks the Access Map for privileges. Token Access Map Token Performance Size of Access Map: 0.02 ms difference between 200 and 2000 rules Request Logging: 0.003 ms overhead Token Verification: key size has large impact. 1024 bit DSA -> 5 ms. 512 bit RSA -> 0.15 ms. Overview: Role-Based Access Control (RBAC) for the LHC & injectors controls systems. Two components: authentication ( A1) and authorization (A2) and the tools to manage access control More details about A1 in TPPA12, and A2 in WPPB08 Status Developed by LAFS, a collaboration between Fermilab and CERN) Deployed June ’07 50 users, 25 roles, > 10,000 rules > 140,000 tokens