1. Introduction to X.509-based Security Features

Next chapter

While GemStone/S 64 Bit has a number of security features, the GemStone server is normally run within a secured environment that is not at risk for malicious attack. Starting with v3.5, GemStone/S 64 Bit also includes support for highly secured remote logins, in which each connection to a process on the Stone’s node is authenticated and the communication is protected by X509 certificates.

The security features in X509-Secured GemStone allows user applications in the cloud, for example, to login to a Stone on a secure node without any risk of compromising the Stone or any sensitive data.

GemStone/S 64 Bit also includes support for generating X509 Certificates, including self-signed Certificate Authority Certificates that allow the use of X509-Secure GemStone in a test configuration. For security, applications should generate certificate-requests and submit these to a external certificate authority. Correct security procedures must be followed in order to create a secure application.

The X509-secured GemStone feature is separately licensed; you must have a keyfile with appropriate permissions in order to use X509-secured logins.

 

1.1 Overview

X509 logins and associated processes, such as X509-secured NetLDIs and X509-secured remote shared page caches, use a different architectural model than ordinary GemStone logins.

Figure 1.1 Overview of components in X509-Secure GemStone
 

Both kinds of logins are supported to a single Stone. However, the supporting processes such as the NetLDI and remote shared page cache are not shared between these two kinds of logins, which places some restrictions on the topography for configurations that will use both regular and X509-secured logins.

  • X509-Secured NetLDIs
    To mediate the secure login, NetLDIs must be started in certificate-only mode on both the remote Gem host and the Stone’s node, configured with the appropriate certificates. X509-Secured NetLDIs only support X509-Secured login, and X509-Secured logins require X509-Secured NetLDIs; you may run both X509-Secured and regular NetLDIs on the same node.
  • New Host Agent process
    Each remote node that will hold an X509-Secured process needs to have a Host Agent running on the Stone’s node. An additional script, starthostagent, must be executed on the Stone’s node after both NetLDI are started, and before logging in. starthostagent executes for a single specific remote node, and requires the appropriate certificates.
  • Startup of the remote cache
    The act of starting up a remote cache is initiated when the (starthostagent) script is executed for that remote node.

When instructed by the newly started HostAgent, the remote shared page cache that supports the secure login is started up by the remote NetLDI. The remote cache is configured based on specific new arguments to startnetldi that were passed in when the remote NetLDI was started.

  • Login Parameters
    Both secured and ordinary logins can be done to the same Stone at the same time, but they must use different NetLDIs. Secure logins are performed using new C calls that require a different set of login parameters than ordinary logins. Specific set commands in topaz, new GCI functions, and GemBuilder for Smalltalk parameter editor and classes added in GBS v8.4 support X509-secured logins.

X509-Secured login only can be done for RPC logins. Linked logins do not use certificates.

  • Connections initiated from Stone’s node
    All interprocess connections are initiated from the Stone’s node. So, for example, when an application logs in, it provides a listening socket to the HostAgent on the Stone’s node, but the secure connection is initiated by the HostAgent.

This also means that if the X509-Secured remote cache times out and shuts down (which occurs after a timeout, when no sessions are logged in and using that remote cache), which shuts down the Host Agent on the Stone’s node, you must execute starthostagent again on the Stone’s node before further X509-Secure logins are possible on that remote node.

  • Mid-level caches must also be X509-Secured
    If a remote node is to be used as a Mid-Level cache by X509-Secured Gems, it must also be started in certificate-only mode with specific configuration values that give it the ability to act as a mid-level cache.
  • Object Filters
    Additional object-level security is provided in an X509-Secured GemStone, which allows you to define object access security by IP address. This allows applications to avoid the risk that sensitive data may be present in a remote cache.

There are no differences in the way the Stone is configured and started up, although some configuration parameters (such as those managing the use of SSL) are not relevant for X509-secured sessions.

Next chapter