Security class customization: Knowledge prerequisites
A set of security classes is delivered with the Landmark environment and with each Landmark application. These delivered security classes have names ending in "_ST" to indicate that they belong to the "standard template" set of security classes. You cannot modify these security classes, so if these do not suit your business needs, you must create customized security classes. Customized security classes can then be assigned to roles and actors (users) can be assigned to the roles, so that they have the appropriate access to your Landmark system.
You create customized security classes in the Configuration Console, which is accessible through the Infor Rich Client or Web UI. You can create an empty security class or, as is usually easier, you can create the new security class by copying an existing class. Once you create a new security class, you can add or modify security rules for that class in the Configuration Console.
Securable Objects
To write appropriate security rules, you need to be familiar with both the types of objects can have security rules written against them and you need to be familiar with the specific instance of those object types that exist in the part of the system you are attempting to control access to. All of the securable object types are listed in the Configuration Console's left pane whenever you select a security class to work. The objects are described briefly below. The Configuration Console also exposes the available specific securable objects in drop-down lists when you are defining security rules.
When you select a securable object, a button to activate the Condition Builder appears. Condition Builder allows you to create conditions for the object. Available actions vary by type of object. Only objects that can have conditions written are available through Condition Builder.
You can also identify the specific objects within a data area by using the Data Menu widget in the Infor Rich Client or Web UI. By expanding the Data Menu for a data area, you can identify the modules, business classes, menus, fields, business tasks, web applications, and so on that are within the data area.
| Type | This refers to the types of business objects that can be secured. For example, if you grant unconditional access to the business class type, you are granting access to all business classes. |
| DataArea | This refers to the data areas that exist in your system. There will be a gen data area and a data area for each Landmark application that you have installed. |
| Module | This refers to subsets of a data area. Each module represents a set of related business classes and tasks. |
| WebApp | This refers to a set of modules, menus, and pages designed as an application that may be viewed in a browser or in the Infor Rich Client or Web UI (for example, the lsuserapp or UserManagement web applications). |
| Menu | This refers to the menus that are defined in a data area. |
| KeyField | This refers to the fields that are designated as business class key fields. When you write security rules for a key field, you generally specify that the access is "for all ontology." An ontological rule propagates a security specification throughout the system, wherever the key field is included in the context of an object. When a access is granted to a key field, any business class containing that key field in its context will inherit access. |
| BusinessClass | This refers to a related set of fields, somewhat analogous to a database table, but more complex in that a business class also encompasses business logic. |
| BusinessTask | This refers to certain actions that are securable. For example, for users to be able to work with the queues, they must have access to several business tasks for the execution of the queues. |
| Executable |
This refers to securable programs within the system that perform a specific process task. |
Security Policies and Rules
A security policy is the set of security rules for a securable object. In many cases, there is one rule per policy, but there can be multiple. There are several aspects of security rules to keep in mind as you create them.
| Action Rules | Choose the type of action the security rule applies to. You can have the security rule apply to all actions or to one or more actions that are available for the object you are securing. In addition, you can specify to grant access to all actions, but then specify one or more individual actions to be excluded. |
| Inclusion Versus Exclusion | You can grant access or deny access when you write a rule. Users do not have access to data areas, modules, business classes, and key fields unless access is explicitly granted. However, if a user is granted access to a business class, the user has implicit access to the fields in the business class unless access to one or more is explicitly denied. |
| Conditional Rules | You can write rules that applied in specified circumstances. For example, in the ProxyInquireAccess_ST class, a user can only have access to actor proxy records if the user is the actor to whom the proxy was granted. |
Landmark Pattern Language (LPL)
If you plan to update rules by editing the LPL, which requires Configuration Console on the Web, you must have a strong knowledge of LPL. Information is available in Landmark Pattern Language (LPL) Guide.