InterSystems IRIS Data Platform 2019.2  /  Security Administration Guide

Security Administration Guide
Previous section           Next section
InterSystems: The power behind what matters   

There are various pathways for connecting to an InterSystems IRIS™ instance for users, applications, and even other InterSystems IRIS instances. These pathways are managed by InterSystems services, which serve as gatekeepers for connecting to InterSystems IRIS. Because InterSystems services are the primary means by which users and computers connect to InterSystems IRIS, 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 InterSystems IRIS 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 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 the section “Integration with InterSystems Security” in the “Introduction to Studio” chapter of Using Studio.
%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.
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.
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 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, 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 in the “Horizontally Scaling Systems for User Volume with InterSystems Distributed Caching” chapter of the Scalability Guide.
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 InterSystems IRIS database mirroring. For more details about mirroring generally, see the “Mirroring” chapter of the High Availability Guide; for more details about security for mirroring (though the use of SSL/TLS), see the “Configuring InterSystems IRIS to Use SSL/TLS with Mirroring” section in the “Configuring InterSystems IRIS to Use SSL/TLS with Mirroring” chapter.
This service manages connections that serve up web pages. Specifically, it manages connections between the Web Gateway and the InterSystems IRIS server.
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 for IPv4 and ::1 for IPv6.
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 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.”
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 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, and %Service_Shadow.
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.
Services with Authentication Mechanisms
Service Name KRB Cache KRB Login Del LDAP OS IA Un
%Service_Bindings N Y Y Y N Y Y
%Service_WebGateway 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
%Service_WebGateway N Y Y Y N Y Y
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 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 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 the chapter “Resources.”
Independent of privileges for other resources, service privileges provide little to the user.

Previous section           Next section
Send us comments on this page
View this book as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-08-23 05:35:26