Version 24.2.9039

• Users
  • Single Sign-On
  • Admin API Access
  • Password Resets
• User Roles
  • Admin Role
  • Standard Role
  • Support Role
  • Custom Roles
    • Creating Roles and Policies
    • Associating Users with Roles
    • Role and Policy Example
  • User Roles Comparison Table

The first time you launch CData Arc, the application prompts you to create the first application user by setting a username and password. The first user defaults to the Admin role, as defined below.

Users

To create and manage additional users, navigate to the Settings page, then the Users tab. This tab includes a table of all users, and includes information about their roles, Admin API access tokens, Federation Id (for single sign-on), and more.

Members of the Admin role can create, delete, and modify users on this tab. Admin is the only role with permission to manage other users.

Single Sign-On

Arc supports single sign-on (SSO) via identity providers that implement the OpenID standard. For more information, including specific guidance for Azure AD, see Single Sign-On.

Admin API Access

Each user is granted an Auth Token that can be used to access the Admin API. For more information on authenticating against the Admin API, see Admin API Authentication.

The specific actions that a user can perform using the Admin API mirror the actions that the same user can perform using the UI. For example, a user that cannot delete connectors in the UI cannot use the Admin API to delete connectors. To perform any action using the Admin API, use an Auth Token from an Admin user when invoking the API.

Password Resets

If an administrator is locked out of Arc, the embedded web servers in each edition provide the ability to reset the administrator’s password to regain access to the application. For example, in the Cross-Platform edition:

java -jar arc.jar -ResetPassword -User <user> -Password <password> -AppDirectory <appDirectory>

In the .NET edition:

CData.Arc.exe -ResetPassword -User <user> -Password <password> -AppDirectory <appDirectory>

User Roles

The Roles tab displays a table of all roles defined in the application, along with the associated workspaces and a link to all users who can assume each role. Roles enable you to restrict users to only performing certain actions in certain workspaces. The roles assigned to a user affect everything that they see in Arc, including but not limited to:

• Workspaces
• Reports
• Dashboard data
• Logs

Every installation of Arc includes three built-in roles:

• Admin
• Standard
• Support

These are global roles that cannot be edited or deleted. They apply to all workspaces. However, you can define custom roles which limit each user’s permissions. Custom roles are made up of policies, which provide the most granular control over exactly what users can see or do in Arc. An individual user can be assigned to a maximum of 10 roles, and each role can include up to 10 policies. Custom roles also identify which workspace(s) users can see and interact with.

The following sections describe each built-in role, explain how to define new policies and roles, and provide some example policies. Use the comparison table for help building your own policies and roles.

Admin Role

The Admin role provides full control over the application. An admin can create new flows, delete existing flows, change Profile settings, and perform every other operation supported by the console.

In addition, only admins can view the Audit Log, which records all changes made by any user in the application.

Standard Role

Members of the Standard role can create, edit, and delete connectors and flows. However, they cannot change any application-wide settings, such as those exposed in the Profile page.

Standard users can upload new files into flows, and can upload public certificates for use by connectors. They cannot upload private certificates that are set in a Profile.

Support Role

The Support role is a read-only role; members of this role cannot create or delete flows, or change application settings. Support users can send files through existing flows using the Send operation, but cannot upload new files (in other words, they can only process files already present in the Input tab of a connector).

Custom Roles

Custom roles give you more granular control over what each user can see or do in Arc. Custom roles are defined by creating policies, which specify the exact permissions members of that role have. Custom roles also identify which workspace(s) users can see and interact with. An individual user can be assigned to a maximum of 10 roles, and each role can include up to 10 policies.

Creating Roles and Policies

1. To create a custom role, navigate to the Settings page, then the Roles tab.
2. Click Add. Give the role a meaningful name and description, then click Next.

3. Check the checkboxes next to the policy Workspace and Connector permissions you want to assign, then click the Select Workspaces link to assign the policy to one or more workspaces. The following image shows a completed Policy 1 section.

   

4. To add another policy, click Add Policy and repeat the previous steps.

5. When you are finished, click Save Role. The following image shows a role with two policies.

   

Associating Users with Roles

1. To add users to the role, click the Associated Users tab.
2. Click Add Users, then select the user(s) who can assume this role.
3. When you are finished, click Save Role.

4. Use the Roles tab to view summary information for each role, including the associated workspaces and users.

   

Role and Policy Example

Imagine a scenario where your company has a group of EDI developers. The company has multiple trading partners; we will use two trading partners and two developers for this example.

The trading partner flows are broken up into two separate workspaces: PartnerA and PartnerB. Each EDI developer (DevA and DevB) works primarily in their corresponding workspace (DevA = PartnerA), but they also need to be able to view or send files as necessary in the PartnerB workspace. To manage this, you can create the DevA user, create a custom role for DevA, and assign two policies to the role, as shown in the following image.

• Policy1 gives DevA full access to the PartnerA workspace.
• Policy2 gives DevA limited access to the PartnerB workspace, allowing them to view and send files, but not create or delete connectors, or modify flows or settings.

User Roles Comparison Table

This table describes the functionality available in all types of roles.