There are various pathways for connecting to a Caché instance for users, applications, and even other Caché instances. These pathways are managed by Caché services, which serve as gatekeepers for connecting to Caché. Because Caché services are the primary means by which users and computers connect to Caché, their management is an essential part of security administration.
Topics in this chapter are:
The Services page (System Administration > Security > Services) provides a list of services that Caché provides.
There are two groups of services:
Resource-based Services — These are services that provide user access to Caché. This kind of service needs the authentication and authorization infrastructure of Caché security, so it has an associated resource and uses the various available authentication mechanisms.
Basic Services — These are services that provide connections between a Caché server and a Caché application. These do not have associated resources, so they provide little more than the basic security functionality of being turned on or off. Enabling or disabling them controls all forms of access.
The following lists the available services, what each controls, and what kind of service it is:
%Service_Bindings — SQL or Objects; use of Studio [resource-based]
%Service_CSP — Web application pages (CSP or Zen) [resource-based]
%Service_CacheDirect — Cache Direct [resource-based]
%Service_CallIn — The CallIn interface [resource-based]
%Service_ComPort — COMM ports attached to a Windows system [resource-based]
%Service_Console — Terminal from a Windows console (analogous to %Service_Terminal for macOS, UNIX®, and Linux) [resource-based]
%Service_DataCheck — The DataCheck [basic]
%Service_ECP — Enterprise Cache Protocol (ECP) [basic]
%Service_Login — Use of $SYSTEM.Security.Login [resource-based]
%Service_MSMActivate — MSM Activate protocol [basic]
%Service_Mirror — Caché database mirroring [basic]
%Service_Monitor — SNMP and remote Monitor commands [basic]
%Service_Shadow — Access to this instance from shadow destinations [basic]
%Service_Telnet — Telnet sessions on a Windows server [resource-based]
%Service_Terminal — Terminal from a Mac, UNIX®, and Linux console (analogous to %Service_Console for Windows) [resource-based]
%Service_Weblink — WebLink [basic]
The table of services includes a column for each service property.
Notes on Individual Services
For the %Service_Bindings service, there are a pair of resources that manage access: the %Service_Object resource and the %Service_SQL resource. Once a user has authenticated, these two resources control whether data is accessible to the user as either objects or SQL respectively. (If a user has table-level SQL privileges on data, then Caché automatically grants an authenticated user the %Service_SQL:Use privilege for the duration of the connection.)
This service also controls access to Studio. For more information about Studio and security, see the section “Integration with Caché Security” in the “Introduction to Studio” chapter of Using Studio.
This service authenticates connections to Caché through the Caché Direct server. The Caché Direct server is available on any supported platform; clients for this service can only be on Windows.
%Service_CacheDirect manages access for two types of client-side applications:
Client applications that use the Caché Direct client software. These have all authentication mechanisms available.
Client applications that use the legacy CacheObject.dll library. These have no security features available; for these legacy applications, the %Service_CacheDirect service must enable the Unauthenticated mechanism only.
Since legacy applications can only support unauthenticated access and both types of client applications use the same service, Kerberos authentication is not available for Caché Direct clients if Caché is configured to accept connections from a legacy application; similarly, if a Caché instance is configured to accept Kerberos-authenticated connections from Caché Direct clients, legacy clients cannot connect to it.
CacheObject.dll is supported for legacy applications only. New development should use either the Caché Direct client or the CacheActiveX.dll and the %Service_Bindings service.
%Service_Console and %Service_Terminal
These two services both provide console or terminal-style access to Caché. This functionality is analogous for both Windows and non-Windows systems; %Service_Console provides this functionality for Windows and %Service_Terminal provides this functionality for UNIX®, Linux, and Mac.
Terminal or console access is one of the most sensitive aspects of Caché security. If an attacker gains access to Caché in one of these ways, it can be possible to read or destroy sensitive data.
This service manages connections that serve up CSP pages. Specifically, it manages connections between the CSP Gateway and the Caché server.
Under the following circumstances, there is no access to the server via the CSP Gateway:
There are authentication mechanisms enabled for the service
The CSP Gateway has no valid authentication information for any of the enabled authentication mechanisms
Unauthenticated access is disabled for the service
Hence, if you disable unauthenticated access through this service (that is, the Unauthenticated authentication mechanism is disabled), you must ensure that the CSP Gateway has the information it needs to authenticate to the Caché server. For example, for Caché login (password) access, this is a valid username-password pair; for Kerberos access, this is a valid service principal name and key table location. To specify authentication information for the CSP Gateway, use its management interface; for a standard installation, the URL for this is http://localhost:57772/csp/bin/systems/module.cxw, where localhost represents 127.0.0.1 for IPv4 and ::1 for IPv6.
Because %Service_CSP regulates the use of the Portal and its subapplications, disabling %Service_CSP does not disable any system applications, so that there can always be access to the Portal. For more information on system applications, see the “Built-In Applications” section in the “Applications” chapter.
If you inadvertently lock yourself out of the Portal, you can use emergency access emergency access mode to reach the Portal and correct the problem; this is described in the “Emergency Access” section in the chapter “System Management and Security.”
This service regulates the use of the DataCheck utility, which provides a mechanism to compare the state of data on two systems. For more details, see the “Data Consistency on Multiple Systems” chapter of the Caché Data Integrity Guide, and, for security issues, particularly the section “Enabling the DataCheck Service.”
A resource does not govern the use of ECP. Rather, you either enable or disable the service (this makes ECP what is called a “basic service”). This means that all the instances in an ECP configuration need to be within the secured Caché perimeter.
See the “Specifying ECP Privileges and Roles” section of the “Configuring Distributed Systems” chapter of the Caché Distributed Data Management Guide for details on how privileges work within an ECP configuration.
This service controls the ability to explicitly invoke the Login method of the %SYSTEM.SecurityOpens in a new tab class. Calls to this method are of the form:
Set Success = $SYSTEM.Security.Login(username, password)
where username is the user being logged in and password is that user’s password.
This service regulates the use of the Caché database mirroring, which provides automatic failover between two systems. For more details about mirroring generally, see the “Mirroring” chapter of the Caché High Availability Guide; for more details about security for mirroring (though the use of SSL/TLS), see the “Configuring Caché to Use SSL/TLS with Mirroring” section in the “Configuring Caché to Use SSL/TLS with Mirroring” chapter.
This service regulates the use of a Caché instance as a shadow source. For more details, see “Configuring the Source Database Server” in the “Shadowing” chapter of the Caché Data Integrity Guide.
Caché includes support for a number of legacy services. These are all basic services, and can simply be enabled or disabled. They include %Service_MSMActivate and %Service_Weblink.
Each service has a set of properties that control its behavior. These can include:
Service Name — Specifies the identifier for the service.
Description — Provides an optional description of the service.
Service Enabled — Controls whether a service is on or off. When enabled, a service allows connections to Caché, subject to user authentication and authorization; when disabled, a service does not permit any connections to Caché.
At system start up, each service has the same state (enabled or disabled) that it had when Caché was shut down. Note that enabling or disabling a service is not simply a security setting. It determines whether or not a certain capability is provided by Caché and may, for instance, determine whether certain daemon processes are started or memory structures are allocated.
Allowed Authentication Methods — Specifies the available authentication mechanisms for connecting to the service, including either of the two-factor authentication mechanisms; if multiple mechanisms are selected, the user or client can attempt to connect using any of these. The mechanisms available depend on what is selected on the Authentication/CSP Session Options page (System Administration > Security > System Security > Authentication/CSP Session Options). If a service supports multiple authentication mechanisms, these are used according to the Caché rules of cascading authentication.
If either two-factor authentication mechanism is enabled, it has a check box. If visible, these are:
Two-factor Time-based One-time Password — A Caché user’s mobile phone or an authentication device serves as a second authentication “factor”; Caché and the phone or device share a secret key. This key is used to generate a time-based one-time password (TOTP), which the user must enter at a prompt as part of the authentication process.
Two-factor SMS — A Caché user’s mobile phone serves as a second authentication “factor”; Caché sends a eight-digit security token to the phone, which the user must enter at a prompt as part of the authentication process.
For more details, see the section “Configuring Two-factor Authentication” in the “Authentication” chapter.Note:
If two-factor authentication is enabled for an instance, this check box appears on the Edit Service page for all its services. However, two-factor authentication is only available for %Service_Bindings, %Service_Console, and %Service_Terminal (and only when it is enabled for the instance).
Allowed Incoming Connections — Specifies a list of IP addresses or machine names from which the service accepts connections; if a service has no associated addresses or machine names, then it accepts connections from any machine. This capability can be very useful with multi-tier configurations; for example, with the CSP service, it can be used to limit the set of Web servers that can connect to Caché. The Allowed Incoming Connections facility for ECP has additional features described in the Restricting ECP Application Server Access section of the Caché Distributed Data Management Guide.
For a resource-based service, the service can be specified as public. Public services are available to all authenticated users, while non-public services are available only to those users with Use permission on the service’s resource. This value is displayed on the main Services page (System Administration > Security > Services) and is set on the Edit Resource page for the service’s resource. Possible values are:
N/A — The service has no associated resource; this means that service can simply be turned on or off.
NO — Access is available to any user holding a role that has the Use permission on the service’s resource. This is checked after authentication.
YES — Access is available to any user.
A change to a service only takes effect after the service is restarted.
Services and Authentication
Basic services do not support authentication for Caché security. They are simply turned on and off. For those services, enabling the service ensures that it accepts all connections. For these services, the assumption is made that all instances or machines using the service are within a secure perimeter and can only be accessed by valid users. This includes %Service_ECP, %Service_MSMActivate, %Service_Monitor, %Service_Shadow, and %Service_Weblink.
To enable an authentication mechanism for a resource-based service, you must first enable it for the Caché instance on the Authentication/CSP Session Options page (System Administration > Security > System Security > Authentication/CSP Session Options). Resource-based services support authentication mechanisms as listed in the table below. If a service has more than one authentication mechanism enabled, Caché supports cascading authentication.
|Service Name||KRB Cache||KRB Login||Del||LDAP||OS||Caché||Un|
KRB Cache — Kerberos Cache
KRB Login — Kerberos Login
Del — Delegated authentication
LDAP — LDAP authentication
OS — Operating-System–based authentication
Caché — Caché Login
Un — Unauthenticated access
For each resource-based service, if there are multiple enabled authentication mechanisms, then Caché attempts to authenticate users going from the strongest enabled form of authentication to allowing unauthenticated access (if that is enabled). This is process is described in the section Cascading Authentication in the “Authentication” chapter.
Services and Their Resources
For resource-based services, the properties of the service itself govern access to Caché; at the same time, the properties of the service’s resource govern access to and behavior of the service. For all resource-based services except %Service_Bindings, the service’s associated resource has the same name as the service itself; hence the %Service_CSP resource manages access for the %Service_CSP service. (The %Service_SQL and %Service_Object resources manage access for %Service_Bindings.)
A resource itself has only two related properties: whether or not it is public and, if it is public, what its public permissions are; for a service resource, the only relevant permission is Use. If it is public, then all users have Use permission on the service. For more information on resources, see the chapter “Resources.”
Independent of privileges for other resources, service privileges provide little to the user. For example, for the %Service_CacheDirect:Use privilege to be useful, the user must also hold the %DB_<database-name>:Write privilege for the database where updates are to occur.