Name- and Access-server in the GSI Control System

Outline

Clients request the data needed to access a device from a central server, the name- and rights-server. The nameserver in the GSI control sytem covers two main areas:

• managing address information of the devices (e.g. CORBA IORs) in the GSI controls environment
• handling rights for access to devices in the GSI control system

Thus, the name- and access-server has two main functional parts: The address handling, including some additional device information, and the rights handling. A third important module handles the communication with the name- and access-server.

Access Rights Mechanisms

Concept

The GSI control system supports several criticality levels. Each property of a device is assigned to one of the criticality levels, which are read, modify, system and admin. To access the property, the client process has to have the corresponding right. Rights are staged, any right level includes all lower levels.

Access rights in the GSI control system are granted to users: A user has to have the required right to access a property of a device. Client processes use the right level of the user which runs the process. Consol process run under a specific user name, allowing to give operators in the main control room general rights.

Rights are assigned to users for devices. To simplify handling, set-up of the rights can be simplified by selecting devices by their type (equipment model) or locations in the accelerator (area). You can find additonal information on basic concepts and on managing access rights.

Implematation Schematic

Each device generates random numbers for each of the supported criticality levels. These numbers, called access patterns, are provided to the name- and rights-server as part of the device information.

During the instantiation of a client device proxy, access information are requested from the name- and rights-server. This includes the address resolution (e.g. the CORBA IOR) and an access pattern.

The access pattern is send to the front-end device in each access. The front-end device determinies the criticality level from the access pattern. To execute the property access, the reconstructed criticality level has to fit to the criticality level which is assigned to the property.

To reconstruct the criticality level from the transfered access pattern, the access pattern has to correspond to one of the access pattern which the device has generated. The access patterns being random numbers, detecting a valid pattern (a pattern corresponding to one of the patterns of the device) ensures that the client has requestested the pattern from the name- and rights-server.

Using random number access patterns, stored in the name- and right-server, allows to concentrate the handling of user rights in the name- and rights-server. Bypassig this central server by re-building the CORBA interface from the freely available IDL interface would not work, since a valid access pattern would be needed.

Device Data Handling (Including Addresses)

For each device, identified by its nomenclature, the device data handling stores the following information:

• The access address. Presently, only the stringified CORBA IOR of the front-end device servant is supported. In principle, stringified address information of any exchange protocol (e.g. SOAP) could be handled.
• The equipment type (equipment model) of the device.
• An optional secondary equipment type (equipment model). This is used to store the equipment type the devices which are handled by a front-end EC controller.
• The access pattern, the device specific representation of the criticality levels of the properties.

Name- and Rights-Server: Access Rights Handling

Upon a client requests for the access information for a device-nomenclature, the name- and rights-server performs the following steps:

• Retrieve the device data for the given nomenclature. This includes
  • The stringified address data (the IOR).
  • Equipment type, and secondary equipment type.
  • Access patterns, one for each criticality level.
• Determine the access right of the requesting user. This results in a criticality level which the user may execute for the given device.
• Select the access pattern, corresponding to the access right of the user.
• Send the stringified address dataand the selected access pattern to the client process.

Determination of the access right for a user is done in a two staged process. Stage one:

• Firstly, the access right is determined for the user name, dewtermined by the client's access interface. This is the user name under which the client process runs.
• Secondly, the right is determined for an additional user name the client process may specify in the access interface.
  This step is executed only if the client has specified the additonal user name.
• The right with the lower criticality level is assigned to the client process for the given device.

Using an explicit additional user name in the client's access interface allows to restrict the access in a context which otherwise would result in high user rights. This is used by server processes, which transfer Userface commands to the DeviceAccess clent interface. The server process rund with high rights and has to restrict the rights for each Userface-user.

In a second stage, the access right is determined, both for the primary user name as well for the additional user name, for both equipment types, stored in the device information:

• Request the access right for the equipment type (equipment model), assigned to the device nomenclature.
• If this criticality level is less than admin or system, and a secondary equipment type is given:
  • Request the access right for the secondary equipment type (equipment model) of the decvice
  • If the criticality level is localsystem, set the access right for this device to system

The reason for the maybe confusing check for the secondary equipment type is: A user to which the access right 'localsystem' was granted for an equipment type will receive the criticality level 'sytem' for all EC equipment controllers hosting this specific equipment type, but will have only the EC specifc right for all other EC equipment controllers.

Secondary equipment types presently are foreseen for EC front-end controllers only.

The main classes of the access right handling area are shown in a class diagram (show). The actions to determine the access pattern for a device access is demonstrated in a schematic sequence (show), where the main domains of the name- and rights-server collaborate (show).

Communication

Communication with the name- and access-server is by a TCP/IP based protocol. It supports several synchronous request:

• Request access information by device access clients. This is handled internally in the client interfaces, which are supported for C++, Java and Python.
• Request device information from the name- and rights-server, like all nomenclatures for a given equipment type.
• Store device information, provided by the devices during their instantiation.
• Execute commands to manage the name- and rights-server may be send, like update the rights information.