The purpose of this article is to make a practical sense of attempting to configure the Maximo Security model using Person Groups to provide the filtered / restricted data applicable for various business groups i.e. Mechanical, Engineering, HR etc. or using vendor field to filter / restrict the data for external vendors performing maintenance on their Assets only as it is being attempted for few clients.
This article is the view presented by the team DawnBIT based on its experience around Maximo.
- How Maximo handles user’s access profile?
Maximo uses a two-step security process that consists of ‘authentication’ and ‘authorization’
- In first step, users are authenticated if they can even login to Maximo or not.
- In second step, they are validated, what all applications, functions they are authorized to use.
Note: User has to be a member of some security group (MAXGROUP) for getting authorized. It’s a group-based authorization and not individual user based. A user can belong to multiple security groups. So, authentication is applied for an individual user, but authorization works for a group (MAXGROUP).
- How Maximo’s handles Group Security access profile?
Maximo authorizes each security groups (MAXGROUP) using other security related Objects e.g.:
- Access to various site for an Organization using SITEAUTH object.
- Access to various Application usings MAXAPPS Object and access to various select actions is granted using SIGOPTION objects. Here you can apply some conditional access rules too.
- Storeroom level access is handled using LOCAUTH object.
- Other Data Restrictions can be applied using
- For object level data restrictions, we can use SECURITYRESTRICT.OBJECTNAME
- For attributes level data restrictions, we can use SECURITYRESTRICT.ATTRIBUTENAME. We need to identify the object for the attribute before putting the data restrictions at attribute level.
- COLLECTIONAUTH.COLLECTIONNUM for Collections. A collection is a group that can contain assets, locations, and classification items.
- There are few other options available for controlling access using Security Groups (MAXGROUP) like LABAUTH for Labor authorizations, LIMITTOLERANCE for Limits and Tolerances etc.
- How Maximo defines various Levels of Objects to handle Multi-Org and Multi-Site setup?
For Multi-Org & Multi-Site setup, Maximo has 12 different data filter levels defined for Maximo Objects
| Level | Description | Object attributes | Example |
| SYSTEM | A system-level object. Security restrictions are applied at the application or object level in the specific system-level business object definitions. | System attribute | |
| SYSTEMORG | A system-level object that can also be assigned to an organization. If the organization ID is not specified, the object operates at the system level. | System attribute and organization attribute | orgid is null or orgid = … |
| SYSTEMSITE | A system-level object that can also be assigned to a site. If the site ID is not specified, the object operates at the system level. | System attribute and site attribute | siteid is null or siteid = … |
| SYSTEMORGSITE | A system-level object that can also be assigned to an organization, or to an organization and a site. If the site ID is not specified, the object operates at either the system level or the organization level. The level depends on whether the organization ID is assigned. If the organization ID is not specified, the object operates at the system level. | System attribute, organization attribute, and site attribute | (siteid is null or siteid = …) and (orgid is null or orgid = …) |
| SYSTEMAPPFILTER | This object is treated as a system-level object but it can ask the profile for a list of sites and organizations in the context of an application so that the application can filter data. Filtering is required for site-level administration of users and groups. Used for Users and Groups. | System attribute and application filter attribute | |
| ORG | An organization-level object. The framework applies security for this type. | Organization attribute | orgid = … |
| ORGSITE | An organization-level object that can also be assigned to a site. If the site ID is not specified, the object operates at the organization level. | Organization attribute and site attribute | (siteid is null or siteid = …) and orgid = … |
| ORGAPPFILTER | An organization-level object with application filtering. Used for contracts so that the contract applications can filter on the special object instead of filtering by using standard security. | Organization attribute and application filter attribute | |
| SITE | A site level object. | Site attribute | siteid = … |
| SITEAPPFILTER | A site-level object with application filtering. Reserved for future objects. | Site attribute and application filter attribute | SITEAPPFILTER |
| ITEMSET | An item set-level object. The itemsetid attribute value must exist in the insert organization for users. The framework adds the required security restriction. | Item set attribute | |
| COMPANYSET | A company set-level object. The compnaysetid attribute value must exist in the insert organization for users. The framework adds the required security restriction. | Company set attribute |
- Can Maximo be configured to restrict data for internal departments like Mechanical, Engineering, HR etc and for Asset Maintaining Companies to access their data only ?
Yes, Maximo provides enough options to play around Maximo Objects and Applications for applying the data restrictions through Maximo Security Groups (MAXGROUP) and it can easily be configured to restrict data for internal departments and external Asset maintaining vendors for their data access only.
- Can Person Group be used Maximo be configure for data restriction for internal departments like Mechanical, Engineering, HR etc and for Asset Maintaining Companies to their data only ?
When we check Person Group (“persongroup.persongroup”) using SameASObject and SameAsAttribute in MAXATTRIBUTECFG then we will find 70 plus objects using it having multiple validation classes. This seems to be enough for using it as we can add field to the objects where it is missing.
A person group (PERSONGROUP) is a list of individuals with similar job responsibilities, levels of authority, and security clearances but you can create person groups having ‘zero’ authentication or authorization i.e. they might not to be Maximo users (MAXUSER) at all forget about being part of security groups (MAXGROUP).
As Person Group (PERSONGROUP) are not directly related Security Group (MAXGROUP) and they can exist totally independent of each other. So, for using Person Groups for achieving data restrictions, we will have to create a tight-coupling with the Security Groups which will kill configuration flexibility provided by Maximo. Any ‘Tight-Coupling’ or ‘Hard-Coding’ should be a ‘No’ for any customization.
We will lose the freedom of creating Security Groups as needed by our business but will have look into the tight-coupled Person Groups for any change.
Conclusion: Applying data restrictions to User Groups outside the Security Group (MAXGROUP) object and its related Objects, is not a practical solution as this works on the huge assumption that Security Groups and the functions that these Security Groups will perform, are immutable, which is never the case in real life where one size can never fit all.
- Can Vendor (COMPANIES.COMPANY) field be used in Maximo for data restriction for Asset Maintaining Companies to work on their data only?
No, As we have concluded for Person Group, using any fields which are outside the Security Group (MAXGROUP) object and its related Objects, its not a viable solution.
- Can such a configured System replicated as a ‘Product’ for other clients?
No, it can only be attempted but can’t be replicated ‘as-is’ as a ‘Product’. For every new implementation, Maximo will have to be reconfigured as per the client’s business requirements.