Using Lawson Security with Existing Programmatic Security

The information contained in this section is a summary only. Anyone who writes Lawson Security rules needs Lawson application knowledge. This is especially true when writing rules that leverage existing programmatic security.

This section discusses implementation on the Lawson Security side only. Setup is required on the application side, too. The application installation guides provide setup information. In addition Lawson application experts have contributed articles to the Lawson Knowledge Base that provide additional, necessary information.

Lawson Security is compatible with security that exists in Lawson applications. This includes security referred to by such names as, "Company and Process Level security," "Accounting and Account Unit security," "HR security," "900 API security," and other kinds of application-based security. Most of these types of security make use of an element or element group.

As discussed earlier in this document (and in other Lawson documents), elements and element groups are global objects that are recognized across multiple programs and, in some cases, even across product suites. Elements and element groups are typically things like Company field (element) or Company and Process Level fields together (element group).

When a application that makes use of programmatic security executes, it interrogates Lawson Security about whether or not the user has access to the particular element or element group. If the user does, the program gives access to the user.

The subsections that follow explain, in general, the types of security that exist in Lawson applications. They also describe the rules that you should write for each type.

Lawson has created a spreadsheet that identifies the securable objects (except for application forms) in 8.1 applications that make use of programmatic security. (Application forms that make use of Company and Process Level security are identified in a different way. For more information, see the section "Determine if Company and Process Level security is in use for an application form") This spreadsheet is in the Lawson Knowledge Base and is called "Lawson 8.1 Applications with Programmatic Security." The subsections that follow refer to the columns in the spreadsheet.

Note: In addition to the rule that you write to leverage element, element group, or other type of application-defined security, a security class must include access to all securable objects a user needs, including programs, system codes, and all data files.

Programs secured by Company

This section refers to securable objects that have the following in the "Type of application security" column in the spreadsheet:

  • 900-ACTIVITY-GROUP-SECURITY

  • 900-COMPANY-SECURED

  • 900-COMPANY-SECURITY

  • 900-CHECK-RWSECURITY

In Lawson Security, for each security class in which you want to control Company level access, you must write a rule on the Company element that grants access appropriately. This ensures that Company security within the application gives a user access only to any data he or she should see.

The screen clip that follows gives an example of a how you might write a rule on the Company element.

Screen clip: Writing a rule on the Company element in Expression Builder

Programs secured by Company and Process Level

This section refers to securable objects that have the following in the "Type of application security" column in the spreadsheet:

  • 900-PROC-LEV

In Lawson Security, for each security class in which you want to control Company and Process Level access, you must write a rule on the element group PROCLEVEL (a special element group delivered by Lawson Security) that grants access appropriately. This ensures that Company and Process Level security within the application gives a user access only to any data he or she should see. (In some cases, the application uses a different term for Company and Process Level, for example, Company and Location. For all applications, the application installation guides tell you the name of the element or element group that is used by the application.)

One of the scenarios in this guide shows an example of this type of rule. For more information, see the section "Rule to link the PROCLEVEL element group to objects that are secured by Company and Process Level".

Programs secured by Account-Unit

Some Lawson programs make use of Account-Unit security, which means they validate Company and Account or Activity Group Security Code and Activity. These programs have the following in the "Type of application security" column in the spreadsheet:

  • 900-ACCT-UNIT

  • 900-RWSECURITY

  • 900-COMPANY-SECURITY

Lawson Security treats these types of programmatic security as if they were secured by Company and Process Level. This means that you would write rules on the PROCLEVEL element group that point to either Company and Account or Activity Group Security Code and Activity, whichever is used by the application. (For all applications, the application installation guides tell you the name of the element or element group that is used by the application.)

Programs secured by HR security

This section refers to securable objects that have the following in the "Type of application security" column in the spreadsheet:

  • 700-HR-EMP-SECURITY

  • 730-HR-FIELD-SECURITY

HR provides security of access to the Employee record through validation against Security Location and Security Level. The Employee security location and security level are set up using HR11 and stored on the Employee record.

For programs of type 700-HR-EMP-SECURITY, you must write rules on both the PROCLEVEL and HREMP element groups. For the PROCLEVEL, point to Company and Process Level. For the HREMP rule, point to Security Location and Security Level.

Programs of type 730-HR-FIELD-SECURITY do not make use of elements or element groups. The data file, HRSECLEV, validates data. This means that you do not use PROCLEVEL and HREMP in your rules. You can simply write rules that grant access to the securable object and let the application validate against the data file. (You can also write additional, conditional rules in Lawson Security if you want to. The point is that the application ensures that users can only see the appropriate data even when a grant all access rule is used.)

Note: HR Security is a complex subject that is covered in detail in the HR documentation and in Lawson Knowledge base articles. Read this material before attempting to work with HR Security.

Application-defined security

This section refers to securable objects that have any of the following in the "Type of application security" column in the spreadsheet. "Type" in this case is actually the data file that these programs are validated against.

  • APUSER

  • AROPTR

  • CBUSER

  • OPERATOR

  • PASCRTY

  • RQAPPCODE

  • RWUSER

These programs are not element or element group based. This means that you do not write rules on an element or element group. You can simply write rules that grant access to the securable object and let the application validate against the data file. (You can also write additional, conditional rules in Lawson Security if you want to. The point is that the application ensures that users can only see the appropriate data even when a grant all access rule is used.)

How to use the spreadsheet

The programmatic security spreadsheet provides an alphabetic listing of all securable objects—other than application forms secured by Company and Process Level security—that have programmatic security. The spreadsheet shows the type of programmatic security that is being applied. When you are ready to write a rule on an application securable object, check the spreadsheet to see if it uses programmatic security. If it does, review this appendix to locate the type of security and determine the type of rule you should write for this object.

Note: You use a different method to identify application forms that use Company and Process Level Security. For more information, see the section "Determine if the Company and Process Level security is in use for an application form".
Illustration: How to use the programmatic security spreadsheet

You will notice that many securable objects listed in the spreadsheet have more than one type of security listed. This is because the spreadsheet takes into account any invoke that a program calls. You only need to write one rule for the security class to identify the type of application security that is used.