Since you can use application resources to escalate a user’s roles, they provide a mechanism for meeting authorization needs that shift dynamically. To perform privilege escalation for an application:
User-Based and Application-Based Security
The InterSystems security model allows for flexible privilege assignment that can be user-based, application-based, or both. The use of an application can be limited to specific users or open to any users. For those users authorized to use the application, there can be several behaviors:
-
The application can run with the user’s privileges alone.
-
The application can escalate privileges for only some users (using matching and target roles).
-
The application can escalate privileges for all users (using application roles).
-
The application can escalate some privileges for all users and only escalate other privileges for certain users (using a combination of matching/target roles and application roles).
Hence, you have control of whether application use is limited to specific users or open to any users; simultaneously, you also have control of whether an application runs with the user’s privileges or with its own privileges. This enables InterSystems IRIS to provide a very flexible model:
Protection/Escalation Matrix for Secured Applications
Privilege Level / Protection Level |
Public Application |
Restricted Application |
With User-Dependent Privileges |
1. Any user can run the application. Application runs with user privileges. |
2. Only specified users can run the application. Application runs with user privileges. |
With Privilege Escalation |
3. Any user can run the application. Application runs with (expanded) application privileges through application roles and matching roles. |
4. Only specified users can run the application. Application runs with (expanded) application privileges through application roles and matching roles. |
Each of the scenarios described in the previous table is commonly used for a different authorization model:
1. Public Application with User-Dependent Privileges
This describes an application available to any authenticated user; when run, the application grants no additional privileges. For example, for a company’s contact database, any user belonging to the company-wide role can get the office phone number and email address for any employee; managers hold greater privileges, which entitle them to view employee home phone numbers; HR staff hold even greater privileges, which entitle them to view and update full records. The application is accessible to all employees, and its behavior depends on privileges that each user already has when invoking it — the application itself grants no roles.
2. Restricted Application with User-Dependent Privileges
This describes an application available only to a user who belongs to a specified role; when run, the application grants no additional privileges. For example, a company may have a payroll application for its hourly employees, which displays the number of hours worked, pay rate, and so on. To run the application, a user has to be a member of either the HourlyEmployee role or the HourlyManager role. Once running, the application checks which role was present: members of HourlyEmployee can see and not edit their own data, while members of HourlyManager can see and edit data for their own reports. An employee who is a member of the HourlyEmployee role can run the application to check the accuracy of personal data; any other employee (such as one on a salary and who is not a member of the required role) cannot even run the application.
3. Public Application with Privilege Escalation
This describes an application available to any authenticated user; when run, the application escalates privileges based on the roles to which the user belongs. (The application can also escalate privileges only for certain roles.) For example, suppose a university has an application where students can review and update their records. Here, any student is an authenticated user and can edit his or her own contact information. To support this functionality, the application includes code for editing an entry; this code checks that the entry being edited matches the authenticated user and, if so, escalates its own privileges to update the record, and then restores the privileges to their previous state. If one student attempts to update another’s record, then the check fails, there is no privilege escalation, and the update does not occur. The application might also check if the user is a member of the registrar’s office role, in which case it would be possible to update information more widely.
4. Restricted Application with Privilege Escalation
This describes an application available only to a user who belongs to a specified role; when run, the application escalates privileges based on the roles to which the user belongs. (The application can also escalate privileges only for certain roles.) For example, a hospital’s emergency room might have an application that grants the attending doctor special, wider privileges for viewing the records of patients currently admitted for emergency care. Because of the potentially critical nature of emergency-room cases, the doctor needs to be able to view more information in this setting than while simply making rounds; hence, the privileges are escalated.