Access Control

An efficient and secure system to protect the access to data is a key part of the security concept in CDA. Administrators can grant user and user groups access to the features, objects and views that they are entitled to see based on their role and responsibilities within their company.

Security at data level can be as broad as administrator access to a role, or as granular as “Read access to just one job in one specific folder between 8:00 am and 4:00 pm on Tuesdays”. Any user interaction with Jobs or Workflows is logged for easy viewing and reporting.

This page includes the following:

Segregation of Content Using Clients

Users, User Groups and objects are allocated to Clients, which are the largest organizational units in an Automation Engine system. Each Client can have an administrator user that manages the necessary authorizations. Only administrators of Client 0 (also called system Client) can create further Clients and carry out global configuration and maintenance activities.

Client 0 is already available after installation and system administrators can log in to it using the UC/UC user object with password UC. It is recommendable to change this password after the first login.

You can create up to 9999 Clients and configure them to depict your business as best suits you. A 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.

Planning an efficient Client landscape that segregates content and access rights is the basis for a secure access to data. See Example: Creating a Basic Client/User Landscape.

Access Rights Based on User Roles

Automation specialists who design Workflows need access to Login objects that grant processes access to third party systems. However, they do not need rights to create and define those Login objects. Operators who monitor and analyze active and ended tasks do not need rights to define and edit the underlying objects.

The authorization system supports the separation of administration, design, implementation and operation, adding a security layer. This separation takes place at various levels:

The Automic Web Interface provides a visual and clear segregation through perspectives, which are areas on the User Interface that provide access to features according to functions and roles. It is possible to grant or deny Users and User Groups access to perspectives. See Perspectives and User Roles.
A privileges system grants or denies access to entire areas of the Automic Web Interface and to role-specific functions. See Granting Automation Engine Privileges.
User Groups can be defined based on the functions and objects they should have access to. They help you keep the maintenance of security and data access manageable. You assign User Groups access to specific folders and objects, as well as privileges to functions.
Users are allocated to User Groups depending on their role. A user can be member of more that one group.

Based on the User Group definition, administrators can then create catalogs for operators that facilitate their access to the views, objects and functions that they have rights to. Users can only see and work with these and have no access whatsoever to any other area of the system. See Example: Configuring the User Catalog.

ACL Aggregation

In order to reduce security management effort, the Automation Engine allows you to group objects through intelligent filter criteria, for example using object naming conventions. See Granting Automation Engine Authorizations.

Restrictions at Object and Folder Level

In addition, you can define authorizations for Users and User Groups at object level within every Client. This way it is possible to grant certain users exclusive access rights to a particular object.

Since folders are also objects, you can also control user access to them. However, take into account that specifying folder rights does not automatically prevent access to the objects stored in them. For example, if an object stored in a protected folder is used in a Workflow, users who have rights to edit the Workflow will also be able to edit the embedded object. Objects that should not be accessed by particular users should also be protected. See Folders (FOLD).