InterSystems IRIS Security

Security Elements Within InterSystems IRIS

InterSystems security provides a simple, unified security architecture that is based on the following elements:

• Authentication. Authentication is how you prove to InterSystems IRIS that you are who you say you are. Without trustworthy authentication, authorization mechanisms are moot — one user can impersonate another and then take advantage of the fraudulently obtained privileges.

  The authentication mechanisms available depend on how you are accessing InterSystems IRIS. InterSystems IRIS has a number of available authentication mechanisms. Some require programming effort.

• Authorization. Once a user is authenticated, the next security-related question to answer is what that person is allowed to use, view, or alter. This determination and control of access is known as authorization.

  As a programmer, you are responsible for including the appropriate security checks within your code to make sure that a given user has permission to perform a given task.

• Auditing. Auditing provides a verifiable and trustworthy trail of actions related to the system, including actions of the authentication and authorization systems. This information provides the basis for reconstructing the sequence of events after any security-related incident. Knowledge of the fact that the system is audited can serve as a deterrent for attackers (because they know they will reveal information about themselves during their attack).

  InterSystems IRIS provides a set of events that can be audited, and you can add others. As a programmer, you are responsible for include the audit logging in your code for your custom events.

• Database encryption. InterSystems IRIS database encryption protects data at rest — it secures information stored on disk — by preventing unauthorized users from viewing this information. InterSystems IRIS implements encryption using the AES (Advanced Encryption Standard) algorithm. Encryption and decryption occur when InterSystems IRIS writes to or reads from disk. In InterSystems IRIS, encryption and decryption have been optimized, and their effects are both deterministic and small for any InterSystems IRIS platform; in fact, there is no added time at all for writing to an encrypted database.

  The task of database encryption does not generally require you to write code.

Secure Communications to and From InterSystems IRIS

When communicating between InterSystems IRIS and external systems, you can use the following additional tools:

• SSL/TLS configurations. InterSystems IRIS supports the ability to store a SSL/TLS configuration and specify an associated name. When you need an SSL/TLS connection (for HTTP communications, for example), you programmatically provide the applicable configuration name, and InterSystems IRIS automatically handles the SSL/TLS connection.

• X.509 certificate storage. InterSystems IRIS supports the ability to load an X.509 certificate and private key and specify an associated configuration name. When you need an X.509 certificate (to digitally sign a SOAP message, for example), you programmatically provide the applicable configuration name, and InterSystems IRIS automatically extracts and uses the certificate information.

  You can optionally enter the password for the associated private key file, or you can specify this at runtime.

• Access to a certificate authority (CA). If you place a CA certificate of the appropriate format in the prescribed location, InterSystems IRIS uses it to validate digital signatures and so on.

  InterSystems IRIS uses the CA certificate automatically; no programming effort is required.

InterSystems IRIS Applications

The InterSystems IRIS security model includes applications, which are configurations that control authentication, authorization, and other aspects of code use. These apply to user interfaces, external executables, and APIs.

For an overview, see InterSystems IRIS Applications.

For details, see Defining Applications.

InterSystems Authorization Model

As a programmer, you are responsible for including the appropriate security checks within your code to make sure that a given user has permission to perform a given task. Therefore, it is necessary to become familiar with the InterSystems authorization model, which uses role-based access. Briefly, the terms are as follows:

• Assets. Assets are the items being protected. Assets vary widely in nature. The following items are all assets:

  • Each InterSystems IRIS database

  • The ability to connect to InterSystems IRIS using SQL

  • The ability to perform backups

  • Each Analytics KPI class

  • Each application defined in InterSystems IRIS

• Resources. A resource is an InterSystems security element that you can associate with one or more assets.

  For some assets, the association between an asset and a resource is a configuration option. When you create a database, you specify the associated resource. Similarly, when you create an InterSystems IRIS application, you specify the associated resource.

  For other assets, the association is hardcoded. For an Analytics KPI class, you specify the associated resource as a parameter of that class.

  For assets and resources that you define, you are free to make the association in either manner — either by hardcoding it or by defining a suitable configuration system.

• Roles. A role is an InterSystems security element that specifies a name and an associated set of privileges (possibly quite large). A privilege is a permission of a specific type (Read, Write, or Use) on a specific resource. For example, the following are privileges:

  • Permission to read a database

  • Permission to write to a table

  • Permission to use an application

• Usernames. A username (or a user, for short) is an InterSystems security element with which a user logs on to InterSystems IRIS. Each user belongs to (or is a member of) one or more roles.

Another important concept is role escalation. Sometimes it is necessary to temporarily add one or more new roles to a user (programmatically) so that the user can perform a normally disallowed task within a specific context. This is known as role escalation. After the user exits that context, you would remove the temporary roles; this is role de-escalation.

You define, modify, and delete resources, roles, and users within the Management Portal (provided that you are logged in as a user with sufficient privileges). When you deploy your applications, however, you are more likely to define resources, roles, and starter usernames programmatically, as part of installation; InterSystems IRIS provides ways to do so.