Defining the Segregation of Duties Report

The Segregation of Duties report lets you perform a query about specific security policies that shows which users have (or do not have) access to a specific object. You can also find out what specific action codes a user has access to, for example, whether the user can modify data or just view it.

This report lists, by user, all policies (rules) for the object you select and policies for all "containment" for those policies (that is, all rules that a specific rule is dependent on).

For example, suppose you defined a Segregation of Duties report to show which users have access to form HR11.1. The resulting report would include all users who have been assigned "all access" to HR11.1. It might also include, annotated as "could meet," users who, through containment rules might also have access to, for example, a data source, system code, or program that could give them access to HR11.1. These users might actually be secured out of HR11.1 through a Company and Process Level assignment or other conditional rule. The rule will appear in the report and you will be able to review it. In addition, as the report continues its evaluation, it will provide further details. The point is that, because the report has the goal of identifying any users who should not have access, a great deal amount of information might be produced, depending on the complexity of your security setup. (If you need additional information about how the report evaluates, review the examples in the document Lawson Administration: Resources and Security.)

With the Segregation of Duties report, you can select specific securable objects to query on (forms, data files, data sources, programs, and so on).

You can also drill deeper in these objects to select specific content to query. For example, suppose you want to know who has access to the PAY-RATE field in the EMPLOYEE data file. You can specify to the field level in the Segregation of Duties report. (The results will always include containment in the "could match" section.)

Note: Because the Segregation of Duties report evaluates all security policies for all users, it can, depending on the number of users at your site and the complexity of your rules, take a significant amount of time to process.

The following procedure assumes you want to create a new report definition.

To define the Segregation of Duties Report

  1. From the Lawson Security Administrator main menu, select Reports and then select Report Maintenance.
  2. From the Report Maintenance console, select New Report.
  3. From the New Report dialog box, select Segregation of Duties Report.

    The report definition screen appears.

    Form clip: Segregation of Duties Report
  4. Type a name for the report. The name can be up to 30 characters.
  5. Select a data source for the report.
  6. Select a securable type to run the report against.

    Choices are:

    • CAT: category, a system code (for applications) or a group of Environment programs

    • ELG: element group

    • ELM: element

    • EXE: executable (for example, Environment executables such as dbdef or jobdef)

    • PDL: product line or data area

    • PGM: program

    • QUE: job queue

    • RMO: Resource Management object (groups, resources, roles, or structures)

    • TBL: Data table (or data file)

    • TKN: form

  7. Type the name of a securable object that you want to audit use of.

    For example, to check access attempts for HR11.1 and AP20.1, type HR11.1 and then click Add. Then type AP20.1 and click Add. Objects that will appear in the report are listed in the second dialog box. You can click Remove to take an object out of the report.

    You must type the name of the object exactly as it appears in the Lawson Security Administrator Object Selector. If you are typing a form name, such as HR11.1, use all uppercase letters. If you are typing an Environment executable name, such as, jobdef, use all lowercase. (The report does not check for object names. If you type an incorrect name, the report will fail or will not locate any records.)

    If you want your query to retrieve specific content for an object (for example, users who have been specifically denied access to a data field in a data file), include it when you specify the securable object.

    Examples:

    To locate users who have access to the PAY-RATE field in the EMPLOYEE data file, type:

    EMPLOYEE,PAY-RATE

    The data file name (EMPLOYEE) appears first, followed by a comma and then the field name (PAY-RATE) with no spaces.

  8. Select the type of access you want to report on. Choices are:
    • ALL_ACCESS

    • NO_ACCESS

    • Specific action code(s). Type the action code symbol ("I" for Inquire, "C" for Change) and so on. If you are reporting on multiple action codes, separate them with commas ("I,C"). You need to know which action codes are associated with a particular object. (You can see which action codes are available for objects in several locations, including the Lawson Security Administrator when you define conditional rules.)

  9. Click Add to add the current securable object.
  10. To add more objects, report steps 5 through 9. You can use OR or AND operators for multiple criteria. (OR means "add this criteria to the list and include it along with data that meets other criteria." AND means "include data only if it meets this and all previous criteria. If it does not meet all criteria, do not include it.") Typically, you will use the OR operator for your queries but there might be situations in which you need AND.
  11. When you are finished selecting objects, click OK again.

    Your report definition has been created and you are now ready to run it.