OneCloud security utilizes the principles of authentication and authorization. Authentication controls access to the application. OneCloud authentication supports basic authentication as well as single sign-on (SSO).

The authorization principle of the security model controls which platform functionality is available to the user. Authorization is comprised of several components:


Security Roles

Security roles are predefined and are used to enable or disable access to various OneCloud functionality, such as adding users, editing Workspaces, creating Pipelines, or executing Chains. The following security roles are predefined in the OneCloud platform:

  • Read: Ability to see an application object to which it is assigned, but no execution rights.

  • Execute: Ability to run an application object but no write access. This role generally applies to Integration Studio Chains and Data Prep Pipelines

  • Write: Ability to edit an application object, but no rights to create.

  • Create: Ability to add an application object, but no administrative rights.

📓 Create, Write, Execute, and Read roles are cascading. As an example, a group that is assigned the Write role to a given object will also have Execute and Read rights to that object but not Create rights.

Admin Roles

In addition to the security roles highlighted above, there are several administrative roles within the OneCloud platform:

  • Company Admin: Any user assigned to the Admins security group is a Company Admin and has full access - including delete rights - to all application objects.

  • Workspace Admin: All of the users assigned to a security group that has Admin rights assigned have full access to the Workspace. Like the security roles above, the Workspace Admin role is cascading.

  • Security Admin: The security administrator role provides the ability to manage security provisioning.

Security Administrator Role

The security administrator role can be utilized to assign a user the right to manage security for the entire company, for one or more Workspaces, or for one or more Environments. The below outlines the privileges for each Security Admin role:

  • Company

    • Assign Company Security Admin role to other users

    • Assign Workspace Admin role to other users

    • Create and maintain Security Groups

    • Invite and deactivate Users

    • Create Workspaces

    • Register and Update Runners

  • Workspace

    • Assign Environment Security Admin role to other users

    • Assign security roles (Create, Write, Execute, Read) to the Workspace for which the user is assigned the Workspace Security Admin role

  • Environment

    • Assign security roles (Create, Write, Execute, Read) to the Environment for which the user is assigned the Environment Security Admin role

📓 Workspace and Environment security administrators are not able to add additional security administrators to the object to which they have security administrator rights. To add an additional security administrator for an object, a user with elevated security administration rights would need to assign the user. For example, to add a Workspace Security Administrator, the Company Security Admin would need to assign the role.

💥 Company Security Administrators do not have the ability to assign Environment Security Administrators. A Workspace Security Administrator must assign the Environment Security Administrator role.

Billing User

The Billing User security role is designed to allow users to which the role is assigned to review the license details for the application. License information can be found in the Admin section of OneCloud.


Security Groups

Security Groups are used to assign security roles to OneCloud application objects for one or more users. OneCloud is preconfigured with two security groups - Admins and Default.

Admins Group

As noted in the security roles section above, any user assigned to the Admins security group is a Company Admin and has full access, including delete rights, to all application objects. The Admins security group cannot be removed.

Default Group

Every user is a member of the default group. See the Designing Security section below for important considerations when modifying the security roles assigned to the default group. The Default security group cannot be removed.

Unlike Security Roles which are predefined and cannot be changed, additional Security Groups are able added, modified, and removed as needed.

Creating User-Defined Security Groups

Navigate to the Admin section of OneCloud via Applications in the lower-left corner.

  • Select Users and Groups and then select Groups.

  • Hover over the plus (+) icon in the bottom right, and click the lower Create group icon.

  • In the new User Group form, specify a Name and Description for the group.

    • Optionally, the group can be enabled to manage Connections, Runners, or both.

    • Also optionally, users can be assigned to the Group as part of the Group creation process.

  • Click Save to create the Group.

📓 If necessary, review the Adding Users to Groups section below.

When enabling either the Manage Connections or Manage Runners option, the users assigned to the group will have the ability to modify Connections/Runners for the Workspace Environments to which the group has been assigned. The operation that is able to be performed on Connections and/or Runners is determined by the security role assigned to the Group. For example, if a Group is assigned the Create role to an Environment and the Manage Connections option is selected, then users will be able to create new Connections, modify existing Connections, but not delete Connections.

Assigning Roles to Groups

Security roles can be assigned to a user-defined security group once it is created. The security role assigned to a security group defines the rights that users in the group will have to a OneCloud application object.

To assign a security role to a user-defined security group:

  • Navigate to the Admin section of OneCloud.

    💡 Look for Applications in the lower-left corner.

  • Select Users and Groups and then select Access.

  • The list of Groups available is displayed for both Integration Studio and Data Prep.

In the Integration Studio Permissions section:

  • Click the Group Name for which a security role assignment needs to be completed.

  • The list of Workspaces in OneCloud Integration Studio will populate.

  • Check or uncheck the box for the security role to be assigned or removed from the security group.

By default, if a Workspace is not assigned any security role, the Environments within that Workspace are not displayed. Once a security role is assigned to a Workspace, the list of Environments in the Workspace will then be displayed. Assign the appropriate security role to the Workspace, and if applicable, the Environments contained in the Workspace.

To assign permissions to Data Prep Pipelines and Mapping Groups:

  • Click the name of the Group in the Data Prep section.

  • Select Read or Write access for the Pipelines and/or Mapping Groups.

Security Group Example

Assume that a security group named Chain Builders was created. This group could be provisioned with Admin access to the Development Environment of the Finance Workspace, Execute access to the Production Environment of the Finance Workspace, and no access specified to the Sales & Marketing Workspace. This security role assignment would allow any user added to the Chain Builders security group to run, create, edit, and delete Chains in the Development Environment of the Finance Workspace, run Chains in the Production Environment of the Finance Workspace, but have no access to the Sales & Marketing Workspace.

⚠️ Integration Studio security roles for a group can be applied as granularly as an individual Chain. While this is supported, OneCloud strongly recommends against a security model that leverages role assignment at the Chain level. In instances where this level of granularity is necessary, the creation of additional Workspaces is recommended to avoid creating a security model that requires ongoing maintenance for each new Chain added.


Users

OneCloud users are assigned to security groups to enable access to application objects such as Workspaces, Environments, Pipelines, Mapping Groups, and Chains. The rights that an individual user has to any application object are dictated by the security group(s) to which the user is assigned. Be sure to review the Designing Security section below to understand how a user assignment to multiple security groups can impact access rights.

Adding New Users

To add a new user:

  • Navigate to the Admin section of OneCloud.

    💡 Look for Applications in the lower-left corner.

  • Select Users and Groups and then select Users.

  • Click the blue Invite Users icon in the bottom right.

  • Specify the email address of the user.

    • Optionally, select one or more security groups to which the user should be added.

    • All users are automatically assigned to the Default security group.

  • If the user requires single sign-on (SSO), be sure to check the Enable Single Sign-On box.

    • 📓 This check box is only applicable if SSO is enabled in the application.

  • Click the Invite button and the user will be sent an email invitation.

  • Once the user accepts the invitation, they will have access according to the security groups to which he/she has been assigned.

📓 New users can also be invited to the application by hovering over the blue plus sign in the Groups screen and selecting the upper Invite Users icon.

Managing User Assignment to Security Groups

Once a user has been invited to OneCloud, they can be added to or removed from security groups as needed. To manage a user's assignment:

  • On the user group form, which is displayed when creating or editing a User Group, click the blue plus (+) sign to the right of the Users heading.

  • In the search box, type the email address of the user to add to the Group

  • Click the user from the list displayed in the search form.

To remove a user from a security group:

  • Navigate to the Admin section of OneCloud.

  • Select Users & Groups, and then select Groups.

  • Click Edit.

  • Click the vertical ellipse (three dots) next to the user and select Remove.

  • Confirm the removal when prompted.

❗ Be sure to save the group after any users are added or removed.

Defining Security Administrators

In addition to a user being assigned to one or more security groups, security administrator roles are assigned at the individual user level.

To assign a user one or more security administration roles:

  • Navigate to the Admin section of OneCloud.

  • Select Users & Groups and then select Users.

  • Click the edit (✏️) icon for the user to which a security administrator role needs to be assigned.

  • Select one or more security administrator roles to assign to the user.

  • Be sure to review the security administrator section to ensure appropriate assignment of security administration roles.

  • Save the user.


Designing Security

OneCloud application access is governed by the intersection of security roles, security groups, and users. Application object security is dictated by security roles that are assigned to security groups. It is important to remember the admin (Company, Workspace, Environment) object security roles and the rights each provides. Users are assigned to security groups. This association allows the rights of multiple users to be easily maintained simply by updating the role assigned to the group.

In contrast to application object rights, OneCloud security administration is defined by the assignment of security administration roles to individual users.

Understanding these relationships is key to designing security groups that will enable appropriate access to various application components while reducing the administrative burden of maintaining users on the platform. OneCloud strongly recommends creating a security matrix to outline the intersection of users and the access required across the application. Once the activity is complete, security groups can be creating and users assigned appropriately.

Key Design Considerations

Roles are additive, which means that when checking for access, the platform will detect if the user has permission from any of the user groups. For example, if a user belongs to Group A and Group B, they will still have access to a given application object if it is permitted by Group A but not Group B.

Security roles need to be granted with the principle of least privilege in mind. This means that if you grant elevated permissions on a parent object (Ex. A Workspace is a parent of an Environment), the user will implicitly have the permissions assigned to the parent object.

Because all users are assigned access to the Default security group, it is recommended that permissions applied to the default group be reduced to no access across all objects (Workspaces, Environments), and user-defined security groups are instead leveraged.

Did this answer your question?