Example: Defining Authorizations at User Group Level

Defining and maintaining an authorization system based on User Groups is faster, more flexible and more efficient than doing it via the User definition only. This topic describes how to grant/deny access rights and privileges to User Groups and how to assign them Users. After reading this topic, take a look at Example: Configuring the User Cataloga Use Case that describes how to configure User Catalogs based on User Groups.

In this example, an administrator creates two User Groups in Client 100 and grants them the rights and privileges they need to work with the folders and objects available in the Client according to their roles:

  • DEVELOPERS

    Users in this group create PromptSets, write Scripts, design Workflows, etc.

  • OPERATORS

    Users in this group work with the already created objects; they monitor their performance, carry out reporting activities, register processing errors, etc.

Tips:

  • Read Tips and Tricks to learn about functions that can make your work more comfortable.
  • Activate the SECURITY_AUDIT_FAILURE parameter in the UC_CLIENT_SETTINGS VARA object. This will allow you to see detailed information about failed access attempts of users in the Messages pane, and makes it easy to add rights that may be missing for a particular user, if required.

What Will You Learn?

  • How to create User Groups
  • How to grant the User Group CRUD rights to the objects available in the Client
  • How to deny rights to specific folders and objects
  • How granting/denying rights to folders affects what users can see and do
  • How to assign Users to the User Group
  • How to Define Authorizations at User Group Level

Overview

  1. Create the DEVELOPERS User Group
  2. Create the OPERATORS User Group

Create the DEVELOPERS User Group

  1. In the Administration perspective, expand the User Management section and select User Groups.
  2. Right-click anywhere on the list and select Add User Group from the context-menu or click the Add User Group button on the toolbar.
  3. On the Add User Group dialog enter DEVELOPERS and click OK.
  4. The object definition pages open to the Automation Engine - Authorizations page. This is where you specify the folders, object types and (optionally) objects to which the User Group will have access as well as the CRUD rights you grant the group for each folder/object. For more information about the user authorizations, see Granting Automation Engine Authorizations.
  5. Grant DEVELOPERS full rights to the object types they need. The image below illustrates a possible combination of rights in which users in this group will have all rights to work with Scripts, Jobs, File Transfers, Workflows, Schedules, PromtSets and Variables. However, they will not have access to Calendars:

     

    Note: Leaving the Name empty means that Users with authorizations to the object type selected in the Type column will have the activated CRUD rights with all objects of this type.

  6. To define the functional areas to which the users in the DEVELOPERS User Group should have access rights, open the Privileges page and activate the checkboxes next to the functions for which you want to grant privileges. For more information about the user privileges, see Granting Automation Engine Privileges.

    Typically, developer users could have the privileges listed below, but this depends on your company's policy:

    Access to Explorer Folders

    This controls the access to special folders available on the Explorer navigation pane in the Process Assembly perspective:

    • Access to <No Folder>
    • Access to Recycle Bin
    • Access to Version Management folder

    Administrator

    This controls the access to administration activities. The only task for which this user group must have rights is starting objects without having to specify a Login object (they have no authorization to Login objects)

    • File Transfer: Start without Login object specified

    AWI Access Control

    This control the access to perspectives and other working areas. DEVELOPERS need access to the Process Assembly perspective (where they design the objects), to the Process Monitoring perspective (where they check the performance of their objects) and to the Messages (for troubleshooting):

    • Access to Messages
    • Access to Process Assembly
    • Access to Process Monitoring

    View Messages

    Users in this group need view rights to all messages except those meant for system administrators

    • Dump memory trace
    • View all messages from accorded client
    • View messages of the user's respective User Group
    • View security messages

    Access Control

    Users in this group need access to deactivated tasks; they should be able to manipulate tasks statuses and to assume task ownership:

    • Access to deactivated tasks
    • Modify the status of a task manually
    • Take over task

Create the OPERATORS User Group

  1. Operators work with the same object types as developers but they cannot modify them. They should be able to execute and cancel them as well as access their reports and execution data. Their rights could look like this:

  2. Grant users in the OPERATORS User Group the privileges they need. They could look like this:

    AWI Access Control

    Operator need access to the Process Monitoring perspective (where they check the performance of the objects) and to the Messages (for troubleshooting):

    • Access to Messages
    • Access to Process Monitoring

    View Messages

    Users in this group need read rights to the messages that are meant for their User Group only:

    • View messages of the user's respective User Group
  3. Save your changes.

It is possible that some of the User Groups you need to define are quite similar. Instead of creating them from scratch, you can duplicate and edit them (see To Duplicate a User Group).

Next Step:

To facilitate users access to the objects they are entitled to work with, you can configure now User Catalogs. They are the users' personal and interactive dashboards.

See Example: Defining User Catalogs.

See also: