Skip to main content

InterSystems IRIS Security

This page provides an overview of InterSystems security, with emphasis on the topics most relevant to programmers who write or maintain InterSystems IRIS® applications.

For more information about security, see About InterSystems Security.

Introduction

This section provides an introduction to security within InterSystems IRIS and for communications between InterSystems IRIS and external systems.

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

Almost all users interact with InterSystems IRIS using applications. For example, the Management Portal itself is a set of applications. Each application has its own security. The most common kind of application is the web application, which is an application that accesses InterSystems IRIS through the Web Gateway. A web application communicates through the Web Gateway either via REST or via SOAP.

You can define, modify, and applications 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 applications programmatically as part of installation; InterSystems IRIS provides ways to do so.

For more information on InterSystems IRIS applications, 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.

Next sectionLocalization Support
Previous sectionNamespaces and Databases
FeedbackOpens in a new tab