User Management: Defining and Managing the Authorization System

Planning the authorization policy is one of the first things to do when setting up your system. An efficient and secure authorization system comprises the objects and definitions listed below. It is not mandatory to use all of them. Depending on the size, structure and policy of your company, you may opt for one of the following:

  • A simple authorization system in which authorizations and privileges are granted at User level. This is only feasible for very small systems with a small number of users with also few roles.
  • Complexer systems that use User Groups depicting roles in the company, User Catalogs to facilitate their access to functions, etc.
  • Highly complex landscapes in which additional authorizations are defined at object level.

Tips:

This page includes the following:

Clients

Implementing the authorization policy already begins when planning and creating the Clients, which is where you allocate your Users, User Groups, objects, etc. How you define your client landscape depends on the structure of your company and how you decide to depict it.

Clients are the largest organizational units in an Automation Engine system, where all parameters except Agents are client-specific (Agents can be assigned to multiple Clients). This means that you can freely configure your Clients to depict your business as best suits you.

One common way to do it is creating a Client per operational area, department, etc. For example.

  • Client 1 for DEVELOPMENT containing all developer Users and the folders and objects they will have to work with.
  • Client 2 for HR OPERATIONS containing all HR Users and their folders and objects.
  • Client 3 for FINANCE OPERATIONS, etc.

Another possibility is creating one Client per customer, or per type of customer.

Users within a Client may open and work with all the folders and objects in that Client unless you define and manage their authorizations and privileges.

Client 0

Client 0 (also called system client) is already available when you install the Automation Engine. You use it to manage system-wide settings, such as login information, calendars, variables, as well as to create clients, users and user groups that you then move to other clients, to set up agents, etc.

See Example: Creating a Basic Client/User Landscape for information on the following procedures:

  • Setting up a system with Client 0 and other two Clients
  • Creating User Groups and Users in Client 0 and assigning them rights
  • Moving Users from Client 0 to the Client on which they will work

User Groups

User Groups are the basis of an efficient authorization system. You assign them CRUD rights to specific folders and objects and privileges to functions.

For example, if you set up your Clients to represent the departments at your company, the User Groups within a Client could then depict groups of Users that share the same roles and who must therefore access the same folders and objects with the same (or very similar) rights and privileges.

If you apply this structure to your Clients/User Groups, we strongly recommend to also define and apply naming conventions and patterns to your folders and object names. This helps you easily recognize to which User group an object or a Folder belongs. For example, you could define that objects and folders that are relevant for the developers in your company should start with the DEV_ prefix.

Users

You can create Users directly in the Client in which they will work or in Client 0 and then move them to another Client. In any case, all Users defined in an Automation Engine system are also available in Client 0.

When creating Users, you can assign them authorizations to specific folders and objects, CRUD rights and privileges to functions in exactly the same way as you do for User Groups. However, we strongly advice against it. Doing it at User Group level considerably reduces maintenance activities (you define the rights and privileges only once and simply assign Users to the User Group) and improves the transparency of your authorization policy.

With your Automation Engine installation, a standard user is provided in Client 0 that contains all available rights and privileges, namely user UC (username) in department UC with password UC. You use it to log in for the first time and to start configuring your system.

My Catalog

To further facilitate the access of Users to the folders and objects to which they have been granted rights, you can create User Catalogs based on the User Group definitions.

When you add a User Group to your system, it is automatically available on the User Catalog list of the Process Assembly perspective. You add the folders and objects that this particular User Catalog will have access to; the authorizations and rights are already specified in the User Group definition.

This determines which Folders and objects the users will see and what they can do with them when they open their My Catalog perspective.

Automation Engine Folder Authorizations

Folders are objects and, therefore, rights can be assigned to them. Nevertheless, specifying folder rights does not prevent access to objects stored in them. A user who is not allowed to access a particular folder could still access an object of this folder, for example if it is used in a Workflow. The Open command is available from almost anywhere, hence also in Workflows. Therefore, objects that should not be accessed by particular users should also be protected

Automation Engine Object Authorizations

In addition, it is possible to define specific CRUD rights at object level that you assign to either Users or User Groups. This allows you to extend the rights of a User or a User Group with respect to that particular object. The rights you define at object level override the rights specified at User o User Group level.

Important! Combining User and User Group rights with additional object authorizations can lead to contradictory definitions. Use object authorizations sparingly.

Managing Passwords

As a system administrator, you define the criteria that passwords must comply with in the UC_CLIENT_SETTING variable, see UC_CLIENT_SETTINGS - Various Client Settings.

Passwords do not apply to logins via the LDAP connection.

For more information, see Obfuscating Passwords and Password Exit.

See also: