Clients and Users in Automic SaaS

Your Automic SaaS subscription includes a non-production and a production environment. Each environment by default has an administration Client (Client 0) and a production Client (Client 100) and a default user.

Here you can find all the information relevant to the Users and administration and production Clients in your Automic SaaS environments.

This page includes the following:

Client 0 in Automic SaaS

Also referred to as the system Client, Client 0 is the administration Client used to manage internal objects and system-wide settings. System administrators use Client 0 to manage these settings, which affect all other Clients in the system. There can be only one Client 0 in an Automic SaaS environment.

As an Automic SaaS administrator, 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. An environment has only one Client 0, which is already fully configured. You cannot change its configuration. If you need any change, you must place a Service Request through the Broadcom Support Portal.

The basic configuration of Client 0 in Automic SaaS is similar to the configuration in a non-SaaS Automic Automation environment. There are certain folder structures, objects, variables, and so on that are part of any Client 0 definition. For more information, see System Client 0 - Administration Client .

However, the Client 0 features and functions that are available to Automic Automation administrators do differ from those available to Automic SaaS administrators. Since many of the usual Client 0 activities are performed by the Automic SaaS provider, they are restricted for Automic SaaS administrators.

Here you have an overview of what you, the system administrator, are allowed and not allowed to do in Client 0 and your production Clients:

restrictions in Automic SaaS client 0

  • You can add and authenticate Agents. For more information, see Installing and Configuring Agents for Container-Based Systems and Agent Authentication.

  • You can create Users both in Client 0 and directly in the production Clients. If you create Users in Client 0, you can then also move them to a production Client using the REST API. You can do so using either the REST API or through the user interface.

    For more information, see:

  • You cannot create new Clients yourself, though. To add more business Clients to your environment, place a Service Request through the Support Portal.

  • You cannot carry out system-related actions such as upgrading the system, stopping server processes, configuring telemetry, or enabling traces.

  • You have access to all variables, with the exception of only Read access to system VARAs (UC_SYSTEM_SETTINGS variable).

    Place a Service Request through the Support Portal if you need to adjust some of the parameters of the UC_SYSTEM_SETTINGS variable. For more information, see UC_SYSTEM_SETTINGS - Systemwide Settings.

Important! Make sure that the configuration of Client 0 in your non-production environment is identical to the Client 0 in the production environment. Otherwise, you cannot test your changes under production conditions and you risk corrupting your production Clients.

Production Clients in Automic SaaS

Client 100 is a default production Client included in Automic SaaS. You do not have to use it, if you do not want to.

You can add more production Clients to your environment; to do so, place a Service Request through the Support Portal. You can also configure them to best fit your company's needs.

The production Clients is where users design automation and operators monitor processes. Developers and object designers create and configure objects in a production Client and can also monitor them to ensure that they behave as expected. Also, operators and managers use production Clients not only to understand the configuration and dependencies of the objects but also to monitor them daily and analyze tasks and react, if needed.

For more information, see:

In production Clients, Automic SaaS Users can carry out the same actions than a User in a non-SaaS Automic Automation environment can with only one exception: SQLI Vara objects cannot be used in any Client.

The UC_CLIENT_SETTINGS is a predefined Client variable (VARA) object that allows you to store settings specific to a Client, such as its behavior when started, access control, user passwords, logs and so on. These settings are displayed in the respective Client object, where they can be edited, see UC_CLIENT_SETTINGS - Various Client Settings.

Users in Automic SaaS

The default Users for Client 0 and Client 100 are created automatically and their login credentials are provided to the system administrator. System administrators assign Users to User Groups to define the authorizations and privileges that they have in the respective Clients.

Administrator Users with the necessary privileges can create new Users (other than the first ones) both in Client 0 and in the production Clients. Users can be created either through the REST API or through the user interface,

For more information, see:

Authenticating Users

You have the following options to define the user authentication method in your Automic SaaS environment:

SAML and Automic SaaS

single sign on in Automic SaaS,sso in Automic SaaS

SAML is enabled for Automic SaaS systems. To use SAML in your Automic SaaS environments, you must do the following:

  1. When you create a new User, make sure that the Automic SaaS user name is identical to the user name as defined in your SAML Identity Provider.

  2. Configure your Clients to link your Users to one or more SAML Identity Providers. You do this in the UC_SAML_SETTINGS Client variable available in your Client 0. For more information, see UC_SAML_SETTINGS - Single Sign-On.

The following topic explains how to configure the Automation Engine to set up SSO SAML: Setting up Single Sign-On - SAML. Although this topic is specific for on-premises environments, it will help you understand how Automic SaaS handles SSO. As an Automic SaaS customer, you only have to configure the UC_SAML_SETTINGS variable.

LDAP and Automic SaaS

Automic SaaS supports LDAPS, that is, LDAP over TLS/SSL. To use LDAPS in your Automic SaaS environments, you must do the following:

  1. If you want to set up LDAP for your Users, provide Broadcom with the LDAPS certificate so that we can create the secret for you.

  2. Configure your Clients and Users to connect to the LDAPS server. For detailed information on how to do it, see Configuring Clients and Users to Use LDAP.

Notes:

User Tokens

Automic Automation supports the following authentication methods, Basic Authentication and User Tokens. Depending on your User privileges, you can generate and manage tokens from two different AWI areas:

  • Users with access to their User object definition who have the Token access and token creation privilege.

    You generate and manage your tokens in the Tokens section on the User page in the Administration perspective.

  • All Users, regardless of their User object definition

    You generate and manage your tokens in the Tokens tab on the Settings dialog. For more information see Generating and Managing User Tokens.

User tokens have an expiration date. When a token expires, all requests result in an "Access denied" error message. This is why it is recommended that you create various tokens whose expiration dates overlap so that you can authenticate successfully at any time. System administrators can determine whether tokens are deleted automatically after they have expired in the DELETE_EXPIRED_TOKEN system variable.

Important!

For security reasons, only Automic Automation users can create their own tokens. Administrators CANNOT create the tokens for them. This restriction guarantees that knowledge about the tokens is safeguarded and limited to the User that will use them.

A token is always tied to a User object. However, bad practices when storing and/or using them can lead to accidentally exposing them publicly. It is recommended that you enforce a strong security policy to avoid these situations. These recommendations can help you with it:

  • Protect the token by separating your REST client from the location where you store the token,

  • Delete tokens that are no longer needed.

  • Rotate the tokens periodically and define expiration times that are no longer than necessary and that they comply with your company's security policy.

Managing Password and Agent Login Externally

Agent passwords and login in Automic SaaS,cyberarl with Automic SaaS,manage agent password with cyberark in Automic SaaS,manage agent login in Automic SaaS with cyberark

Automic SaaS supports CyberArk password vaults that retrieve passwords using a REST endpoint. To use CyberArk in your Automic SaaS environments, you must do the following:

  1. Send your certificate to Broadcom. This is necessary so that we can create your secrets.

  2. Configure your password vault. You do this in the UC_VAULT_CYBERARK variable in your Client 0. For more information, see UC_VAULT_CYBERARK - Password Vault Configuration.

Object Authorizations for Client 0 and Client x Objects

client 0 authorizations in Automic SaaS,production clients authorizations in Automic SaaS

Authorizations can also be given at object level. Here also, Automic SaaS Users in Client 0 and production Clients have the same authorizations as non-SaaS Users. The only exception is that Automic SaaS Users only have Read access to the objects that are relevant for the system configuration.

Place a Service Request through the Support Portal if you need to adjust some of the parameters of the UC_SYSTEM_SETTINGS variable or any other objects that are relevant for the system configuration.

For more information about the System Settings, see UC_SYSTEM_SETTINGS - Systemwide Settings.

For more information about User and User Group authorizations and privileges, see:

For more information about authorizations at object level, see Authorizations Page.

See also: