LDAP Authorization Group Models
InterSystems IRIS supports for three kinds of group authorization using LDAP.
Create LDAP Authorization Groups for a Single Instance (Single-Instance Groups)
InterSystems IRIS allows you to create LDAP groups that provide authorization for only a single instance; hence, each of these is known as a single-instance group. To create this kind of authorization group:
-
On the InterSystems IRIS instance, confirm or modify the value of the LDAP parameter Authorization Instance ID. By default, its value is NodeName_InstanceName, where NodeName is the machine on which the InterSystems IRIS instance is running and InstanceName is the name of that instance.
To set the parameter’s value manually:
-
In the Management Portal, go to the Security LDAP Configurations page (Management Portal > System Administration > Security > System Security > LDAP Configurations).
-
On that page, select the configuration to edit by clicking on its name.
-
On the page for editing the configuration that appears, select Use LDAP Groups for Roles/Routine/Namespace.
-
Next, in the Authorization Instance ID field, enter the value for the parameter and click Save.
-
On the LDAP server, define role, namespace, and routine groups with names that conform to the required InterSystems structure and that use the Instance keyword, followed by the value of the Authorization Instance ID. Note that these strings are not case sensitive. These group names are of the form:
intersystems-Instance-AuthorizationInstanceIDValue-Role-RoleName
intersystems-Instance-AuthorizationInstanceIDValue-Routine-RoutineName
intersystems-Instance-AuthorizationInstanceIDValue-Namespace-NamespaceName
where:
-
AuthorizationInstanceIDValue is the value specified for the Authorization Instance ID field
-
RoleName, RoutineName, and NamespaceName are each the name of the role, default routine, or default namespace.
Note:
A user can have any number of roles; typically, access to the system requires at least one role. A user can have only one default routine and one default namespace; however, these are not required, so a user may have no default routine and no default namespace.
-
RoleName can include multiple roles, delimited by a “^”. For example, “%All^Admin^Application4” includes the “%All”, “Admin”, and “Application4” roles.
-
On the InterSystems IRIS instance, configure a role associated with each group.
For example, suppose you are running an application on an instance called Test that is on a machine called Node1. You wish to set up three categories of users:
-
Application users — Can only run the application
-
Administrative users — Can run various administrative tools and the application
-
Superusers — Have full access
To set up this authorization model, create the following groups on the LDAP server:
intersystems-Instance-Node1_Test-Role-Administrator
intersystems-Instance-Node1_Test-Role-LocalApplication
intersystems-Instance-Node1_Test-Role-%All
intersystems-Instance-Node1_Test-Routine-LocalApplication
intersystems-Instance-Node1_Test-Routine-%SS
intersystems-Instance-Node1_Test-Routine-%pmode
intersystems-Instance-Node1_Test-Namespace-%SYS
intersystems-Instance-Node1_Test-Namespace-USER
Next, create the roles that corresponds to each category of user:
-
Administrator
-
LocalApplication
Note:
You do not need to create a %All role, because it already exists.
Finally, create the three categories of users:
-
Application users — Can run only the application, LocalApplication; are assigned to the following LDAP groups:
-
intersystems-Instance-Node1_Test-Role-LocalApplication
-
intersystems-Instance-Node1_Test-Routine-LocalApplication
-
intersystems-Instance-Node1_Test-Namespace-USER
-
Administrative users — Can run various administrative tools and the application; are assigned to the following LDAP groups:
-
intersystems-Instance-Node1_Test-Role-LocalApplication
-
intersystems-Instance-Node1_Test1-Role-Administrator
-
intersystems-Instance-Node1_Test-Routine-%SS
-
intersystems-Instance-Node1_Test-Namepace-%SYS
-
Superusers — Have %All access; are assigned to the following LDAP groups:
-
intersystems-Instance-Node1_Test-Role-%All
-
intersystems-Instance-Node1_Test-Namespace-%SYS
-
intersystems-Instance-Node1_Test-Routine-%pmode
Create LDAP Authorization Groups for Multiple Instances (Multiple-Instance Groups)
InterSystems IRIS allows you to create LDAP groups that provide authorization for multiple instances; hence, each of these is known as a multiple-instance group. To create this kind of authorization group:
-
Determine how the various instances are sharing information among groups. This determines the group for each instance and the information to which users have access.
-
For each instance in the group, modify the value of the LDAP parameter Authorization Group ID to be the same as the other instances in the group.
To set the parameter’s value manually:
-
In the Management Portal, go to the Security LDAP Configurations page (Management Portal > System Administration > Security > System Security > LDAP Configurations).
-
On that page, select the configuration to edit by clicking on its name.
-
On the page for editing the configuration that appears, select Use LDAP Groups for Roles/Routine/Namespace.
-
Next, in the Authorization Group ID field, enter the value for the parameter and click Save.
-
On the LDAP server, set up role, namespace, and routine groups that conform to the required InterSystems structure and that use the Group keyword, followed by the value of the Authorization Group ID. Note that these strings are not case sensitive. These group names are of the form:
intersystems-Group-AuthorizationGroupIDValue-Role-RoleName
intersystems-Group-AuthorizationGroupIDValue-Routine-RoutineName
intersystems-Group-AuthorizationGroupIDValue-Namespace-NamespaceName
where:
-
AuthorizationGroupIDValue is the value specified for the Authorization Group ID field
-
RoleName, RoutineName, and NamespaceName are each the name of the role, default routine, or default namespace.
Note:
A user can have any number of roles; typically, access to the system requires at least one role. A user can have only one default routine and one default namespace; however, these are not required, so a user may have no default routine and no default namespace.
-
RoleName can include multiple roles, delimited by a “^”. For example, “%All^Admin^Application4” includes the “%All”, “Admin”, and “Application4” roles.
-
Configure the required roles on all the instances that are using them.
For example, suppose you have seven ECP application servers attached to five database servers. Two of the database servers are a failover pair, and the other three are async reporting members. All these servers (both the application servers and the database servers) run the SALES application. The application’s end users need a more limited set of privileges and its administrative users need greater privileges. Hence, you set up three categories of users:
-
Application users — Can only run the application
-
Application server administrators — Can run the application; have full access to the application servers and no access to the database servers
-
Database administrators — Have full access to the application servers and administrative access to the database servers
To configure LDAP authorization to support these requirements:
On the LDAP server, define the groups as follows:
intersystems-Group-SALESAPP-Role-%All
intersystems-Group-SALESAPP-Role-LocalApplication
intersystems-Group-SALESAPP-Routine-LocalApplication
intersystems-Group-SALESAPP-Routine-%pmode
intersystems-Group-SALESAPP-Namespace-USER
intersystems-Group-SALESAPP-Namespace-%SYS
intersystems-Group-SALESDB-Role-Administrator
intersystems-Group-SALESDB-Routine-INTEGRIT
intersystems-Group-SALESDB-Namespace-%SYS
Next, create the roles that corresponds to each category of user:
-
Administrator
-
LocalApplication
Note:
You do not need to create a %All role, because it already exists.
Finally, create the three categories of users:
-
Application users – Can only run the application, LocalApplication; are assigned to the following LDAP groups:
-
intersystems-Group-SALESAPP-Role-LocalApplication
-
intersystems-Group-SALESAPP-Routine-LocalApplication
-
intersystems-Group-SALESAPP-Namespace-USER
-
Application server administrators — Can run the application, have full access to the application servers, and have no access to the database servers; are assigned to the following LDAP groups:
-
intersystems-Group-SALESAPP-Role-LocalApplication
-
intersystems-Group-SALESAPP-Namespace-USER
-
intersystems-Group-SALESAPP-Role-%All
-
intersystems-Group-SALESAPP-Routine-%pmode
-
Database administrators — Have full access to the application servers and administrative access to the database servers; are assigned to the following LDAP groups:
-
intersystems-Group-SALESAPP-Role-%All
-
intersystems-Group-SALESAPP-Routine-%pmode
-
intersystems-Group-SALESAPP-Namespace-%SYS
-
intersystems-Group-SALESDB-Role-Administrator
-
intersystems-Group-SALESDB-Routine-INTEGRIT
-
intersystems-Group-SALESDB-Namespace-%SYS
At this point, there is a fully functioning authorization model, but it does not include any superuser access to the database servers (that is, with %All). To add such access, create and add users to the following new group:
intersystems-Group-SALESDB-Role-%All
Configure LDAP Authorization Groups with Mirroring
In you are using LDAP and mirroring, InterSystems recommends using multiple-instance LDAP groups to configure authorization. Create the required multiple-instance groups and configure all the users on all members (including any async members) to use these groups.
Consider the following example, which is based on the group structure defined in the example above. Suppose, additionally:
-
There is a mirror called SALESDBMIR which is a failover pair and three reporting async members
-
You wish to have users with %All, but only on the failover pair
To configure authorization for this mirror:
-
To provide full access to the failover pair, create the group
intersystems-Group-SALESDBMIRFAILOVER-Role-%All
-
To provide full access to the asynchronous members, create the group
intersystems-Group-SALESDBMIRASYNC-Role-%All
-
Set the LDAP parameter Authorization Instance ID on each member in the failover pair to SALESDBMIRFAILOVER.
Important:
Because a disaster recovery (DR) async member may be promoted to failover member, the Authorization Instance ID for any DR async should also be set to SALESDBMIRFAILOVER
-
Set the LDAP parameter Authorization Group ID on the mirror’s asynchronous members to SALESDBMIRASYNC.
-
Next, create the mirror administrators, who have %All access to the application servers; administrative access to the nonmirrored database servers; and %All access to the failover pair only. These users are assigned to the following LDAP groups:
-
intersystems-Group-SALESAPP-Role-%All
-
intersystems-Group-SALESAPP-Routine-%pmode
-
intersystems-Group-SALESAPP-Namespace-%SYS
-
intersystems-Group-SALESDB-Role-Administrator
-
intersystems-Group-SALESDB-Routine-INTEGRIT
-
intersystems-Group-SALESDB-Namespace-%SYS
-
intersystems-Group-SALESDBMIRFAILOVER-Role-%All
-
Finally, create the full administrators, who have %All access to all the members (the application servers, the database servers, the failover pair, and the asynchronous members). These users are assigned to the following LDAP groups:
-
intersystems-Group-SALESAPP-Role-%All
-
intersystems-Group-SALESDB-Role-%All
-
intersystems-Group-SALESDBMIRFAILOVER-Role-%All
-
intersystems-Group-SALESDBMIRASYNC-Role-%All
Create Universal LDAP Authorization Groups
InterSystems IRIS allows you to create LDAP groups that provide authorization for all its instances that use a single LDAP server; these are known as universal authorization groups. To create this kind of authorization group:
-
Enable the use of universal authorization groups for the current instance:
-
In the Management Portal, go to the Security LDAP Configurations page (Management Portal > System Administration > Security > System Security > LDAP Configurations).
-
On that page, select the configuration to edit by clicking on its name, which displays the page for editing that configuration.
-
On the page for editing the configuration, select Use LDAP Groups for Roles/Routine/Namespace.
-
Select Allow Universal group Authorization.
-
Click Save.
-
On the LDAP server, set up role, namespace, and routine groups that conform to the required InterSystems structure. Note that these strings are not case sensitive. These group names are of the form:
intersystems-Role-RoleName
intersystems-Routine-RoutineName
intersystems-Namespace-NamespaceName
where RoleName, RoutineName, and NamespaceName are each the name of the role, default routine, or default namespace. RoleName can include multiple roles, delimited by a “^”. For example, “%All^Admin^Application4” includes the “%All”, “Admin”, and “Application4” roles.
Note:
A user can have any number of roles; typically, access to the system requires at least one role. A user can have only one default routine and one default namespace; however, these are not required, so a user may have no default routine and no default namespace.
-
Configure the required roles on all the instances that are using the LDAP server.
For example, suppose you have an application called LocalApplication and you wish to grant various levels of access to it for users on all the InterSystems IRIS instances that use your LDAP server. Define the following LDAP groups:
intersystems-Role-%All
intersystems-Role-Administrator
intersystems-Role-LocalApplication
intersystems-Routine-%SS
intersystems-Routine-LocalApplication
intersystems-Namespace-USER
intersystems-Namespace-%SYS
Next, create the roles that corresponds to each category of user:
Note:
You do not need to create a %All role, because it already exists.
Finally, create the three categories of users:
-
Application users – Have access to the application on all servers; are assigned to the following LDAP groups:
-
intersystems-Role-LocalApplication
-
intersystems-Routine-LocalApplication
-
intersystems-Namespace-USER
-
Administrators — Have administrative access to all servers; are assigned to the following LDAP groups:
-
Superusers — Have full access to all servers; are assigned to the following LDAP groups:
Other Topics for LDAP Authorization with LDAP Groups
Topics include:
LDAP Group Definition Structure
Group definitions typically include:
-
The group name
-
A declaration of the group’s organizational unit: OU=Groups
-
A declaration of the domain component (DC) such as DC=example,DC=com
-
Any other required information
For example, some possible group definitions might be:
CN=intersystems-Role-Administrator,OU=Groups,DC=intersystems,DC=com
CN=intersystems-Group-MyGroup-Namespace-USER,OU=Groups,DC=intersystems,DC=com
CN=intersystems-Instance-MyNode:MyInstance-Routine-INTEGRIT,OU=Groups,DC=intersystems,DC=com
LDAP Group Name Configuration
InterSystems IRIS allows you to further configure LDAP group names. The following sections describe the default configuration, the configurable properties, and the procedure to change them.
Default Group Name Configuration
By default, LDAP group names use the following syntax:
intersystems-Role-RoleName
intersystems-Routine-RoutineName
intersystems-Namespace-NamespaceName
intersystems-Group-GroupName-Role-RoleName
intersystems-Group-GroupName-Routine-RoutineName
intersystems-Group-GroupName-Namespace-NamespaceName
intersystems-Instance-InstanceName-Role-RoleName
intersystems-Instance-InstanceName-Routine-RoutineName
intersystems-Instance-InstanceName-Namespace-NamespaceName
Group Name Properties
Group names consist of the following configurable properties:
-
OrganizationID — Default intersystems. Replace the intersystems segment of the group name with a user-defined or empty string. For example, if set to OrgABC, then the group name becomes:
OrgABC-Role-RoleName
OrgABC-Group-GroupName-Routine-RoutineName
OrgABC-InstanceInstanceName-Namespace-NamespaceName
If set to the empty string, then the group name becomes:
Role-RoleName
Group-GroupName-Routine-RoutineName
Instance-InstanceName-Namespace-NamespaceName
-
DelimiterID — Default hyphen (-). This is the delimiter between segments in the group name. For example, if set to underscore (_), then the group name becomes:
intersystems_Role_RoleName
intersystems_Group_GroupName_Routine_RoutineName
intersystems_Instance_InstanceName_Namespace_NamespaceName
-
GroupID — Default Group. For example, if set to SystemGrouping, then the group name becomes:
intersystems-SystemGrouping-GroupName-Role-RoleName
intersystems-SystemGrouping-GroupName-Routine-RoutineName
intersystems-SystemGrouping-GroupName-Namespace-NamespaceName
-
InstanceID — Default Instance. For example, if set to SystemInstance, then the group name becomes:
intersystems-SystemInstance-InstanceName-Role-RoleName
intersystems-SystemInstance-InstanceName-Routine-RoutineName
intersystems-SystemInstance-InstanceName-Namespace-NamespaceName
-
RoleID — Default Role. For example, if set to SystemRole, then the group name becomes:
intersystems-SystemRole-RoleName
intersystems-Group-GroupName-SystemRole-RoleName
intersystems-Instance-InstanceName-SystemRole-RoleName
-
NamespaceID — Default Namespace. For example, if set to SystemNamespace, then the group name becomes:
intersystems-SystemNamespace-NamespaceName
intersystems-Group-GroupName-SystemNamespace-NamespaceName
intersystems-Instance-InstanceName-SystemNamespace-NamespaceName
-
RoutineID — Default Routine. For example, if set to SystemRoutine, then the group name becomes:
intersystems-SystemRoutine-RoutineName
intersystems-Group-GroupName-SystemRoutine-RoutineName
intersystems-Instance-InstanceName-SystemRoutine-RoutineName
Mix Different Kinds of Groups
You can use universal groups in conjunction with single-instance or multiple-instance roles.
For example, suppose you:
-
Have an application on multiple instances
-
Are using universal groups
-
Have a user named UserOne who can run the application on all instances, but cannot use it as an administrator on any machine
You would like for UserOne to:
-
Continue to be able to run the application on all instance
-
Additionally, to be able to administer the application on a particular instance, called APPTEST, on a particular machine, called Test
To do this:
-
Set the authorization instance ID on the APPTEST instance on the Test machine to Test:APPTEST
-
Create the following group on the LDAP server:
intersystems-Instance-Test_APPTEST-Role-Administrator
-
Assign this group to UserOne on the LDAP server
-
Create the Administrator role on the APPTEST instance on the Test machine and grant it administrative access
You can also mix authorization groups in other ways. For example, if UserTwo has %All permission on all the instances authenticating to the LDAP server, you can give UserTwo exclusive administrative permission on an instance called SECRET on a machine called Server10. To do this, disable Allow universal groups access and then go through the process of assigning an intersystems-Instance-Server10_SECRET-Role-Administrator to that user.
Nested Groups
On an Active Directory LDAP server, LDAP groups include support for what are known as nested groups. A nested group is a group that is a member of a parent group, which means that all the users who are members of the nested group are implicitly members of the parent group. For example, suppose that there are two LDAP groups defined, known as ABC and DEF. You can make ABC a nested group within DEF; this means that, if a user is a member of ABC, then they are also a member of DEF without explicitly assigning the user to that group.
When searching for a user’s nested groups, InterSystem IRIS returns only groups that are defined as Security Groups on the LDAP server. If you are using nested groups, ensure that any group used as a role for an InterSystems IRIS system is created as a Security Group.
Note:
Systems which do not use nested groups will return both Security and Distribution groups.
How LDAP Groups Regulate Access to InterSystems IRIS
Through their LDAP groups, users receive roles along with a default namespace and a default routine. If the user’s granted roles lack sufficient privilege for any required point of access for an instance, the user then is denied access to that instance; for example, if a user lacks sufficient privilege to use their default routine, that user is denied access.
The following rules also apply:
-
If a user is assigned to a group for a role, but that role is not defined on the instance where the user is logging in, then the user does not have that role on that instance.
-
If a user is assigned to a group for a default routine, but that routine is not defined on the instance where the user are logging in, then the user cannot connect to the instance.
-
If a user is assigned to a group for a default namespace, but that namespace is not defined on the instance where the user are logging in, then the user cannot connect to the instance.