Security Classes

Security Class Inheritance

Security classes can be inherited. This means that when you create a new security class, you can designate a parent security class. The new security class will be based on the parent—that is, it will automatically have all of the rules that you have already defined for the parent class. If you modify the parent security class, the changes are automatically reflected in all security classes that inherit from the parent. (One exception is that if the child security class contains an override for a rule in the parent class, the override is retained.)

Avoid overusing inheritance when creating security classes. As a general rule, if you have created a security class hierarchy through inheritance that has more than three levels, consider redesigning your approach. A three-tier hierarchy might degrade performance.

One appropriate time to use inheritance with security classes is when you have a task that many users must perform, but some users must perform it in a slightly different way. For example, suppose that all managers need to view the salary information of the employees they supervise. Suppose further that there is a select group of managers who need to see salary information of people outside their own group. In this case, you could first set up one security class to enable managers to view the salary information of their employees. You could then set up another class that inherits from the first one, and add rules to enable managers to view the salary information for a wider group of employees. You would assign the first security class to a role that all managers have. You would assign the second class to a role that only the select group of managers has.

Another approach for this scenario would be to use role overrides. The most appropriate use of overriding is when you have a small number of users or cases where the security rules must be slightly different than what you have already defined for a security class.

How Lawson Security Applies Rules

It is important to understand how Lawson Security applies the security rules to determine a user's access privileges in order to understand best how rules should be written.

To check access privileges, Lawson Security gathers up all of the security rules that, for a user, apply to the securable object the user is attempting to access. In so doing, Lawson Security checks:

• the profile assigned to the data source

• the roles assigned to the user

• the security classes assigned to each of those roles (including the security classes from which the classes inherit rules)

• any global element rules

• any rules from role overrides

As Lawson Security considers each rule that applies to the securable object, it is looking for one that grants access. As soon as it finds such a rule, it stops searching through rules and the user is able to proceed. If Lawson Security never finds a rule that grants access, the user receives a message saying that access is denied.

When searching through the rules, Lawson Security may encounter many rules that deny access to a securable object, especially if the user has many roles and the roles have many security classes. However, it is always the most generous rule that wins out. For example, if the rules that apply to a user include one that denies access to an object and one that grants access to the object, then the user has access to the object.

The consequence of the most generous rule winning out is that you must be aware of what rules are contained in the security classes, if you assign multiple security classes to a role or if users will be assigned to multiple roles. You can then judge whether the users with that role should get the most generous access allowed by the security classes, or if you need to make modifications or use overrides so that the users have a more limited access.

In the case of application forms, Lawson Security first determines if the user has access to the containment structure that the object belongs to. For an application form, the containment structure includes the data source, system code (category), and program. If one of a user's security classes contains a rule granting access to an application form, but none of the user's security classes grants access to the form's containment structure, the user does not have access to the form. If Lawson Security does not find access to the containment structure, it performs no further checking and the user receives a message saying that access is denied.