Caché Security Administration Guide
[Home] [Back] [Next]
InterSystems: The power behind what matters   

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:
Available Services
The Services page (System Administration > Security > Services) provides a list of services that Caché provides.
There are two groups of services:
The following lists the available services, what each controls, and what kind of service it is:
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:
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:
  1. There are authentication mechanisms enabled for the service
  2. The CSP Gateway has no valid authentication information for any of the enabled authentication mechanisms
  3. 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 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.Security 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.
Legacy Services
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.
Service Properties
Each service has a set of properties that control its behavior. These can include:
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:
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.
Services with Authentication Mechanisms
Service Name KRB Cache KRB Login Del LDAP OS Caché Un
%Service_Bindings N Y Y Y N Y Y
%Service_CSP N Y Y Y N Y Y
%Service_CacheDirect N Y Y Y N Y Y
%Service_CallIn N N Y Y Y N Y
%Service_ComPort N N Y Y N Y Y
%Service_Console Y Y Y Y Y Y Y
%Service_Login N N Y Y Y Y Y
%Service_Telnet N Y Y Y N Y Y
%Service_Terminal Y Y Y Y Y Y Y
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.

Send us comments on this page
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA