Services

Available Services

The Services page (System Administration > Security > Services) provides a list of services that InterSystems IRIS provides.

There are two groups of services:

• Resource-based Services — These are services that provide user access to InterSystems IRIS. This kind of service needs the authentication and authorization infrastructure of InterSystems security, so it has an associated resource and uses the various available authentication mechanisms.

• Basic Services — These are services that provide connections between an InterSystems IRIS server and an InterSystems IRIS 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 — Native API, SQL or objects; use of Studio [resource-based]

• %Service_CacheDirect — A proprietary mechanism for connecting to other InterSystems products [resource-based]

• %Service_CallIn — The CallIn interface [resource-based]

• %Service_ComPort — COMM ports attached to a Windows system [resource-based]

• %Service_Console — The local Terminal from a Windows console (analogous to %Service_Terminal for macOS, UNIX®, and Linux) [resource-based]

• %Service_DataCheck — The DataCheck utility [basic]

• %Service_DocDB — Document database applications [resource-based]

• %Service_ECP — Enterprise Cache Protocol (ECP) [basic]

• %Service_Login — Use of $SYSTEM.Security.Login [resource-based]

• %Service_Mirror — InterSystems IRIS database mirroring [basic]

• %Service_Monitor — SNMP and remote monitor commands [basic]

• %Service_Shadow — Access to this instance from shadow destinations (for use only with existing configurations) [basic]

• %Service_Sharding — Access to this instance as a shard server [basic]

• %Service_Telnet — Telnet sessions on a Windows server and remote Windows Terminal sessions [resource-based]

• %Service_Terminal — The Terminal from a macOS, UNIX®, and Linux console (analogous to %Service_Console for Windows) [resource-based]

• %Service_WebGateway — Web application pages [resource-based]

• %Service_Weblink — WebLink, which is available as a legacy service [basic]

The table of services includes a column for each service property.

Notes on Individual Services

%Service_Bindings

For the %Service_Bindings service, there are three categories of resources that manage access: Native API, objects, and SQL. The Native API category has four resources that control whether data is accessible to the user through the Native APIs once the user authenticates. These resources are %Native_ClassExecution (controls access to Class Execute Functions, for example: ClassMethodValue()), %Native_Concurrency (controls access to Concurrency Functions, for example: Lock()), %Native_GlobalAccess (controls access to Global Access Functions, for example: Kill()), %Native_Transaction (controls access to Transaction Functions, for example: TCommit()). The %Developer and %Manager roles include %Native_ClassExecution and %Native_GlobalAccess with the Use permission by default.

Note:

InterSystems IRIS prohibits access to routine execution through the Native API. If you need to use routines through the Native API, InterSystems recommends using class execution instead.

Additionally, InterSystems IRIS has the %Service_Object resource and the %Service_SQL resource. These resources control whether data is accessible to the user as objects or through SQL respectively. (If a user has table-level SQL privileges on data, then InterSystems IRIS 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 Integration with InterSystems Security.

%Service_Console and %Service_Terminal

These two services both provide console or terminal-style access to InterSystems IRIS. 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.

Caution:

Terminal or console access is one of the most sensitive aspects of InterSystems security. If an attacker gains access to InterSystems IRIS in one of these ways, it can be possible to read or destroy sensitive data.

%Service_DataCheck

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 Data Consistency on Multiple Systems, and, for security issues, particularly Enabling the DataCheck Service.

%Service_ECP

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, such as a distributed cache cluster, need to be within the secured InterSystems IRIS perimeter.

For details on how privileges work within an ECP-based configuration, see Distributed Cache Cluster Security.

%Service_Login

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.

%Service_Mirror

This service regulates the use of InterSystems IRIS database mirroring. For more details about mirroring generally, see Mirroring; for more details about security for mirroring (though the use of TLS), see Configuring InterSystems IRIS to Use TLS with Mirroring.

%Service_Sharding

This service regulates the use of an InterSystems IRIS instance as a shard data server. For more details, see Horizontally Scaling for Data Volume with Sharding.

%Service_WebGateway

This service manages connections that serve up web pages. Specifically, it manages connections between the web gateway processes running on the web server and the InterSystems IRIS server. You will not interact with this service directly within a web application; instead, the authentication mechanisms are configured within the relevant web application definition.

Under the following circumstances, there is no access to the server via the web gateway:

1. There are authentication mechanisms enabled for the service

2. The web 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 web gateway has the information it needs to authenticate to the InterSystems IRIS server. For example, for Instance Authentication (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 web gateway, use its management interface; for a standard installation, the URL for this is http://localhost:52773/csp/bin/systems/module.cxw, where localhost represents 127.0.0.1 for IPv4 and ::1 for IPv6.

%Service_WebGateway controls only the background authentication between the web gateway processes running on the web server and the InterSystems IRIS instance. As a result, authentication mechanisms for web applications are configured and managed within the relevant web application definition, not by editing the allowed authentication methods of %Service_WebGateway itself.

Because %Service_WebGateway regulates the use of the Portal and its subapplications, disabling %Service_WebGateway does not disable any system applications, so that there can always be access to the Portal. For more information on system applications, see Built-In Applications.

Important:

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 Emergency Access.

Service Properties

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 InterSystems IRIS, subject to user authentication and authorization; when disabled, a service does not permit any connections to InterSystems IRIS.

  At system start up, each service has the same state (enabled or disabled) that it had when InterSystems IRIS 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 InterSystems IRIS 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/Web Session Options page (System Administration > Security > System Security > Authentication/Web Session Options). If a service supports multiple authentication mechanisms, these are used according to the InterSystems IRIS 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 — An InterSystems IRIS user’s mobile phone or an authentication device serves as a second authentication “factor”; InterSystems IRIS 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 — An InterSystems IRIS user’s mobile phone serves as a second authentication “factor”; InterSystems IRIS 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 Two-Factor Authentication.

  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 multitier configurations; for example, with the web gateway service, it can be used to limit the set of web servers that can connect to InterSystems IRIS. The Allowed Incoming Connections facility for distributed cache cluster data servers has additional features, as described in Distributed Cache Cluster Security.

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.

Services and Authentication

Basic services do not support authentication for InterSystems 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_Monitor, %Service_Shadow, and %Service_Weblink.

To enable an authentication mechanism for a resource-based service, you must first enable it for the InterSystems IRIS instance on the Authentication/Web Session Options page (System Administration > Security > System Security > Authentication/Web Session Options). Resource-based services support authentication mechanisms as listed in the table below. If a service has more than one authentication mechanism enabled, InterSystems IRIS supports cascading authentication.

Key:

• KRB Cache — Kerberos Cache

• KRB Login — Kerberos Login

• Del — Delegated authentication

• LDAP — LDAP authentication

• OS — Operating system–based authentication

• IA — Instance Authentication

• Un — Unauthenticated access

For each resource-based service, if there are multiple enabled authentication mechanisms, then InterSystems IRIS 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 Cascading Authentication.

Services and Their Resources

For resource-based services, the properties of the service itself govern access to InterSystems IRIS; 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_WebGateway resource manages access for the %Service_WebGateway 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 Resources.

Independent of privileges for other resources, service privileges provide little to the user.