USER AUTHENTICATION FOR ROLE-BASED ACCESS CONTROL

S. Gysin, C.L.Schumann, A. D. Petrov · 2007

The user authentication system is a part of the RoleBased Access Control (RBAC) project for the high-level LHC Control Software (LSA) at CERN. The project is being developed by LAFS (“LHC at Fermilab Software”) collaboration between control groups at CERN and Fermilab. The function of RBAC authentication is to create, distribute, and manage digital credentials for the users. We had to consider many constraints dictated by the existing control system, and diversity of the used software. This paper describes the general design and implementation of the authentication system in Java and C++. We also give and overview of its additional features, such as Single Sign-On and Role Picker. PURPOSE OF THE PROJECT As described in Role-Based Access Control overview [1], we separate two principal concepts in the design of RBAC: authentication (A1) and authorization (A2). Both parts are implemented independently, as two different systems, which do not interact in any way other then passing the users' credentials from A1 to A2. As appears from its name, the purpose of the RBAC authentication system is to verify the digital identity of a principal (which is either a human user or a program). This can be accomplished in several ways, described below. In any case, if the authentication succeeds its result is a digitally signed authentication token that is returned to the application. The program can use the token whenever it needs to interact with various parts to the control system. For example, the token can be provided as one of the arguments in an RMI call to set a device. Front-ends and the middleware that are receiving such calls will verify the token, thus confirming the identity of the remote party, and can use it as a base for authorization. The RBAC authentication token is a short-term uniform substitute of the real credentials. It gets issued by a central service that can reliably verify the user's identity. Various recipients of the tokens can validate them quickly and easily, and use for making authorization decisions. Because the RBAC project began when all other parts of LHC Control Software have been already completed, its design was the subject to a number of requirements and limitations dictated by the infrastructure in place. Basically, we couldn't change much about how the system operated, so RBAC was built as an additional part on top of the existing components. The RBAC authentication system was not designed to be absolutely secure, or to sustain any possible kind of attacks. It's supposed to be used in a certain environment, were other means of protection, such as network firewalls and monitors, as well as the physical access control, are in place. Based on the analysis of real threats, RBAC was built to protect mainly against human errors, rather than against deliberate efforts to break the system down. The overall design of the authentication system was the result of a trade-off between performance, security, and complexity.

Read the paper · More papers on PaperTik