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. This and the following topics describe the objects involved in it and provide examples of how to do it.

Building up an efficient and secure authorization system comprises the objects and definitions listed below. It is not mandatory to use all of them, though. In accordance to the size, structure and policy of your company, you may opt for a simple authorization system (authorizations and privileges granted at User level; this is only feasible for very small systems with a small number of users with also few roles), for complexer systems (User Groups depicting roles in the company, User Catalogs to facilitate their access to functions, etc.) or for highly complex landscapes in which additional authorizations are defined at object level.

• Clients

  Implementing your company's authorization policy in an Automation Engine system 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 are and the folders and objects they will have to work with), Client 2 for HR OPERATIONS (with all HR Users as well as their folders and objects), Client 3 for FINANCE OPERATIONS, etc. Another possibility is creating one Client per customer, or per type of customer.

  No matter how you decide to set up your Clients, bare in mind that 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.

  Take a look at Creating a Basic Client/User Landscape, a Use Case where we describe how to set up a system with Client 0 and other two Clients, how to create User Groups and Users in Client 0 and assign them the rights they will need and how to move Users from Client 0 to the Client on which they will work.

  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.

• 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 also 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. If you have a small system with just a few Users, you may want to define the authorizations and rights at User level. However, doing so 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.

• 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

• 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.

  Using this option can be tricky! Combining User and User Group rights with additional object authorizations can easily lead to contradictory definitions. Automic therefore recommends using it sparsely.

• Managing passwords

  The longer and more complex passwords are, the less likely it is that they will be decoded. Depending on your company's password policy, you may be requested to define passwords that comply with the following criteria:

  • Maximum/minimum length
  • Lowercase/uppercase
  • Use of digits

  • Use of special characters

    Special characters do not count as upper-case letters. For example, Äa8eq9v1z3 is not a valid password entry for a password that must contain upper-case characters.

  • Not using your user name in the password

  The criteria to be adhered to when specifying a password are defined by the system administrator in the UC_CLIENT_SETTINGS variable (see UC_CLIENT_SETTINGS - Various Client Settings). In addition to the required password structure, this variable also determines the intervals in which passwords must be changed, the number of failed login attempts that is allowed, the default password for new users, etc.

  Password do not apply to logins via the LDAP connection.

  See also Encoding Passwords and Password Exit.

See also: