The Users application and the Security Groups application work together. As an administrator, you first define security groups, then you allocate group rights to users.
You can allocate rights to users from both the Security Groups and Users applications:
In the Security Groups application, add users on the Users tab.
In the Users application, add groups to users' profiles on the Groups tab.
A user's security profile is the combined list of rights the user derives from the groups to which they belong.
The Security Groups application enables you to define these rights by group:
Site - Each implementation of the system must have at least one Site.
Application - You specify Read, Insert, Save, and Delete rights for each application.
Application options - You specify the right to use various options, including Select Action menu items and toolbar options, for each application.
Specific rights for:
- storerooms
- labor
- General Ledger (GL) components
- limits and tolerances (primarily purchasing)
- restrictions (a means to limit rights with the SQL Expression Builder)
When creating a group, you do not have to include information from all of the above in a security group. You can create a group with very specific rights (just one site or one application, for example) or with multiple rights spanning most or all the Security Groups tabs. When you put a user in more than one group, these rights combine. You can view this information on the Security Profile tab in the Users application.
In the system, the general procedure is to grant security rights, not subtract them from a default user with universal rights. The system includes these two rights by default:
a user's ability to change and save their password at login if their password expires
a user's access to the start center
The concept of group rights is intended to parallel functional groupings within a company or facility. For example, you could define groups to closely parallel units such as purchasing, maintenance (work order-related tasks), service desks, and so forth.
The number of groups you create depends on how finely you divide up rights among users. For a small implementation, perhaps you only need a few groups. For a large implementation, with multiple sites, multiple administrators, and the full suite of applications, you likely need a large number of groups.
A user can belong to multiple groups.
When you create groups, you specify (with a check box) whether the group rights are independent of other groups. For complex implementations with multiple sites, this option allows flexibility in granting rights. For example, when you specify rights in two independent groups and assign a user to both groups, you can grant that user Read rights to an application at one site, but full Read/Insert/Save/Delete rights to the same application at another site.
If you do not have multiple sites, the independent status is not applicable. Leave the check box cleared.
When you assign applications to groups, it is important to understand whether the application is a system-, set-, organization-, or site-level application.
If you give a user rights to a system-level application, such as Currency Codes, then any changes that user makes in that application have a system-wide impact. For example, if the user adds a currency code CAN for Canadian dollar, then this currency code can be accessed (Select Value button) in currency fields in relevant applications for all organizations and sites.
If you give a user rights to an organization-level application, such as Chart of Accounts, then any change that user makes in that application affect all sites within the organization. For example if the user adds a GL account to Chart of Accounts for an organization, then this GL account can be accessed from the relevant GL Account fields at all sites belonging to that organization.
The level of the application also controls the records a user can see. For example, site-level applications display data for specific sites; organization-level applications display data that pertain to all sites within an organization.
Security settings in the Users and Security Groups applications are at the system level. However, Approval Limits and Invoice Tolerances are at the organization level.
Site access affects higher level applications in another way. When you grant site access combined with rights to an application that is organization-level or higher, the user has rights to that application for all the higher level entities (organization, set, system) that include the sites he or she has access to.
For example, a company has four sites in two organizations: sites A and B in organization ALPHA, and sites C and D in organization GAMMA. If you grant a user, Helen, site access to site A and application rights to Chart of Accounts, then Helen can change the Chart of Accounts in organization ALPHA. If you grant Helen site access to sites A and C, then she can change the Chart of Accounts for both organizations ALPHA and GAMMA.
The Security Groups chapter in the System Administrator's Guide provides several detailed examples of how security groups can be organized. Be sure to consult that chapter before you implement your security.
Note: If implementation uses an application server to authenticate with an external directory (via LDAP), you will not use the system to perform some functions. These functions include:
Self registration - This function is not supported in conjunction with an external directory.
Setting or changing passwords and password hints - All password-related functions are managed by the directory.
By default, when you use an application server for authentication, the directory manages user and group creation. You can set properties to allow user and/or group creation to be performed directly in the system. The settings of these properties result in certain features being enabled or disabled in the system. See the IBM® Maximo® System Administrator Guide for additional information.