User Permissions, Security Overview

This article details the intricacies of setting up / maintaining the Infogix user permissions / security for the following products : Assure, Insight, Perceive and ER

   User Definitions

Infogix Professional Services created the Infogix Security Matrix Worksheet to aide our customers in planning their user communities, application access and permissions. This spreadsheet is located at the bottom of the page for download, if desired. There are several tabs that build on each other as information is filled in for your organization. We have provided some sample information to help get you started. On the first tab named User Definitions you will find a table showing four sample user roles or groupings, a description, arbitrary Active Directory or LDAP Group names associated with the roles / groupings, and a brief description of the type of permissions for each environment based on business need, all from Development to Production. Conceptually, we want to take existing entitlements for your end users and group them in some fashion. The four main Infogix applications have forty-seven ( thirty-one unique ) Roles in total, so the main idea here is to consolidate thirty-one Roles down to a smaller number ( such as four ) for easier comprehension and maintenance.

   Role-Level Permissions

The Role-Level Permissions tab of the Excel Workbook shows an example of how a corporation ties their groups of entitlements back to the Infogix applications. Use this worksheet to tie the LDAP groupings formulated on the User Definitions worksheet to the Roles based on their descriptions. Each of the four Infogix applications has its own set of Roles or entitlements. As of this writing, there are forty-seven Roles ( thirty-one unique Roles ) across the four applications. This worksheet provides a list of the actual Role names, a short description of each, as well as four columns for each environment tier. You may have more than four environment tiers; add more columns as necessary.

These Roles are defined in the application-specific properties files, namely IA.properties, ER.properties, II.properties, and IV.properties. Historically the ratio of Infogix Roles to LDAP groups has been one-to-one, as it is easier to manage in this fashion. That being said, you may have a one-to-many ratio setup if desired, with groups separated via semicolon.

These Roles directly impact the functionality of the applications; the menu options and links to various pages within the applications are present or absent depending on Role membership. For example, a user in the Security Admin Role ( e.g., with the Security Admin entitlement ) will see the "Security" header and associated links on the Assure sidebar, whereas a user without this entitlement would not see these links within Assure :

Because these Role mappings take place in back-end properties files, they are not regularly modified and access to them is limited. Any changes to these Role mappings would require downtime of the application for re-deployment, which is generally frowned upon. Therefore, it is important to get the Role mappings solidified early in the software installation process.

To continue our example scenario, we can take the four sample LDAP groups and assign them to each of the twelve Assure Roles :

These are then manually propagated into the IA.properties file for Assure during the initial installation phase :

   Object-Level Permissions

Within each application ( except for Insight ) is the concept of a Security Profile, which governs object level permission as a set. Each Security Profile has numerous permission items which can each be granted to one or many users and/or groups. Normally these users and groups are defined in a corporation's LDAP repository.

As other objects are created in the applications, such as Assure Control Entities, ER Recon Models, and Perceive Data Entities, each of these objects must be tied to a Security Profile. The supporting objects then inherit the object-level security settings found in the associated Security Profile.

The Object Level Permissions tab in the workbook is designed to mimic the Security Profile setup
process. All permission items are listed line by line. There are eight Security Profile columns, two for each environment tier. You may have more than two Security Profiles per environment tier; add more columns as necessary.

   Let's look at the following scenario :

You have two teams of employees: team A and team B. Both teams will be using the same Assure application and both have a need to create / edit objects. However, team A should not have the ability to edit team B's Control Entity objects, and vice versa.

Your organization has set up LDAP groups for you called "Team_A" and "Team_B" respectively. If we create two Assure Security Profiles called "Alpha Profile" and "Bravo Profile", we can then edit these profiles so that all team A users have various object-level permissions ( including "Edit Controls" ) in the Alpha Profile and team B users have various object-level permissions ( also including "Edit Controls" ) in the Bravo Profile. Later on, as other objects are created, those objects specific to Team_A will be assigned to "Alpha Profile", and those specific to Team_B, to "Bravo Profile". Based on this setup, team A employees will only be able to work with objects assigned to the Alpha Profile, and team B to Bravo Profile.

Although this will work in theory, your permission requirements are likely more strict than this. You likely will want to restrict access to destructive permission items, such as "Delete All Control Data", so that only Superusers are allowed said functionality. This is best managed by creating additional LDAP groups. One simple approach would be to make an analogy to the four-tiered Role groupings addressed earlier. We can then work with unique LDAP groups for read-only access ( "Team_A_User" ), read and write access ( "Team_A_Developer" ), and Superuser or elevated privilege access ( "Team_A_Superuser", "Team_A_Admin" ). The User grouping should be able to view objects and possibly invoke Controls, but not be able to make modifications. The Developer grouping contains users who make modifications to the objects. We can extrapolate the role descriptions and then apply these concepts to our example scenario :

Because the Infogix applications use a combination of role-based and object-based security, it is important that users in a particular Role are a member of multiple LDAP Groups associated with that Role. For example, if Amy Adams of Team A should have Superuser entitlements, her LDAP user account should be a member of both the "LDAP_SUPERUSER" Group ( fulfilling the role-based requirement ) and the "Team_A_Superuser" ( fulfilling the object-based requirement ). Billy Bonds of Team B would also be a member of the "LDAP_SUPERUSER" Group, but also in the "Team_B_Superuser" Group.