In a basic design of the Java Control System at Fermilab, the data are provided by the Data Acquisition Engines (DAE). In most cases, the DAEs are running on a secure network, protected by the firewall. In order to read or set data, an application needs to access the DAE using Remote Method Invocation (RMI) protocol. The existing protocol designed for client-server connections is quite powerful and comprehensive, but does not provide enough security. Because of that, access to DAEs is controlled mostly by the firewall which applies strong constraints on the network traffic. This leads to some serious limitations for the client applications. Roughly speaking, no applications are allowed to access (read and set) the data from outside a very limited area. The similar problem exists with the database access.
On the other hand, most of the client applications designed in Accelerator Controls Department are supposed to be used by a broad community of people. Some of them do not have a chance to get data directly from the engines. Secure Controls Framework (SCF) was designed to address these security issues; namely, to provide a common protocol that would allow client applications to connects the servers in a secure way. Besides that, SCF provides a new data acquisition API and hierarchy of data objects, which (as I beleive) will be more convenient for development of the client applications.
The architecture of Secure Controls Framework is quite simple:
On the client side, there is a set of classes that implements the server connection,
data acquisition jobs, database access; and provides an
API used in the
applications to access this functionality. Besides that, there is a set of reusable
custom GUI components related
to the data acquisition: for example, an extention of JLabel
that
shows reading or setting values, device selector, and a parameter page.
A process running on the server side accepts the client connections, verifies credentials of the remote users, and establishes virtual secure channels to the clients. Then it works as a bridge between these trusted clients and the data sources (DAEs and the database). Variuos types of data requests from the clients are decrypted, verified, and converted to a format understandable by particular data sources. The data obtained from the data sources is converted, encrypted, and sent back to the clients. The client-server communication works through Java RMI protocol.
The client authentication is provided by Kerberos V5 protocol. Java's GSS-API implementation is ised to transfer client credentials to the server and establish a secure communication channel. In simple phrase, all the security is based on the user's Kerberos ticket: it must be obtained with a third-party authentication program (like kinit or Leash32) before using SCF. The only exception was made for the Main Control Room desktops: they are authenticated without Kerberos, by their IP addresses. See “Using Kerberos Authentication in Java” for details.
As was said, SCF works with two kinds of data sources:
Additional data sources can be implemented as needed.
The client-side code is located in the following packages:
Package | Description | Public API |
---|---|---|
gov.fnal.controls.scf |
Server connection and one-shot data acquisition | Yes |
gov.fnal.controls.scf.acquire |
Basic data acquisition abstractions | Yes |
gov.fnal.controls.scf.example |
Examples of programs | No |
gov.fnal.controls.scf.items |
Implementation of data acquisition objects | Yes |
gov.fnal.controls.scf.naming |
Implementation of JNDI | No |
gov.fnal.controls.scf.remote |
Implementation of RMI objects and transport level | No |
gov.fnal.controls.scf.runtime |
Implementation of client-side data access | No |
gov.fnal.controls.scf.swing |
Reusable GUI components | Yes |
Public API is located in
the highlighted packages. Everything needed on the client side is packed in
scf-client.jar archive. Kerberos Module (krb5.jar) is always required in the classpath.
ScfConfig
and JobDataTable
classes also need to have
Application Framework available.
The system is fully operational. Users are allowed to connect SCF servers from any on-site location. Off-site access is not available so far, and it is a subject of concrete needs. By default, the system will connect to an operational server. If it does not, or if you need to have a list of current servers, please write to apetrov@fnal.gov.
The pilot implementation of SCF is Data Browser application:
[Start Data Browser]
you need to have the cached Kerberos ticket!
In order to decide what technology to use in a new application, you can consider the following arguments:
You can take advantage of Secure Controls Framework if...
You should not use Secure Controls Framework if...