When a user is invited to OneCloud, they are added to the Default Group. Every user will belong to the default group, so this will act as the baseline permissions for all OneCloud tenant users. Any permissions can be applied to the default group, but know that any changes to this group will be applied to all users.
No Access Default Group
In production OneCloud scenarios, it is recommended that permissions applied in the default group be reduced to no access and use custom configured security groups.
Administrators in OneCloud are allowed full access to any Workspace, Environment, or Chain in OneCloud. In addition, they are the only users allowed to create Connections and invite others to the platform. See the below section to learn more about inviting users, and note that membership in the admin group is what determines if the user is an administrator or not.
Only add users to the Admin Group who need full tenant access.
If a user has "Admin" privileges to any workspace, that user is considered to be a "Workspace Administrator". This privilege allows a user to create and edit connections that are only available to their Workspace. In addition, under the Admin area, they will also be able to view Runners to check GroundRunner status and the BizApps to see a list of available BizApps.
If a user belongs to the Admin Group, they can invite a user to a OneCloud organization. Navigate to the Admin -> Users and Groups -> Users and hover over the “+” icon in the bottom right, and click the “Invite users” icon. This will open a form where a user can be invited to a OneCloud tenant and one or more user groups can be assigned.
When inviting a user, fill in their email and be sure to select which groups they will be added to by using the dropdown on the right. The selected groups will show up below the user’s email address. Lastly, there is a checkbox to configure the user for single sign-on. To learn more about enabling SSO, please see the Single Sign-On (SSO) documentation.
Also, please note that more than one user can be invited at a time by clicking the “+” icon at the top right of the form.
Navigate to the Admin -> Users and Groups -> Groups and hover over the “+” icon in the bottom right, and click the “Create group” icon. This will open a form where a new group can be invited to a OneCloud tenant and one or more users can be assigned.
The primary way to manage user permissions is by assigning certain permissions to groups and subsequently assigning groups to users. To set permissions on a group, navigate to the Admin -> User and Groups -> Access. This will open a form that will display the available groups. Select a group and a page with explicit permissions will display segmented by Workspace, Environment, and Chain. This approach provides further levels of granularity with setting permissions all the way down to the Chain level.
OneCloud security supports the following permissions:
- Read: User can view the relevant object without making any changes.
- Execute: User can execute a Chain (applied at a Chain-level only).
- Edit: User can make changes to the relevant object.
- Create: User can create new objects (i.e. new Chains in an Environment).
- Admin: User has full access (including the ability to delete) to objects.
If permissions are not set at a granular level, they will be inherited from the closest "parent". For example, if there is "Edit" permission set on a Workspace and not on any Environments, the user would have permission to edit all of the Environments and chains in the Workspace.
Before setting more granular permissions, set the group’s permission level for a Workspace. Workspace permissions are useful for granting broad-strokes access if more detailed permissions are not required. That being noted, the real power of OneCloud’s user administration is to grant fine-grained access to Environments and Chains.
Workspace permissions can be set as Read, Edit, Create, and Admin. This is easily performed by setting the appropriate permission to an individual Workspace.
Once Workspace permissions are established, Environment and Chain permissions can be set. Click on the relevant permission for the Environment which will enable a button to set Chain permission. Each chain within the Environment will automatically have the permission selected at the Environment level.
Restricting Access to Certain Environments
Environment permissions are most useful for restricting users from a production Environment.
Chains have most of the same permission settings as Workspaces and Environments, with the additional capability of controlling whether or not the user can execute a particular Chain. In addition, the “create” permission is not relevant to Chains and is therefore not selectable.
To remove a permission, click on the checkbox of the highest permission of the relevant object (note that the lower permission checkboxes will be disabled). Be careful when removing permissions on Workspaces and Environments, as removing these will revoke permissions that had previously been set on child objects.
Once chain permissions have been set, users will now be restricted at the appropriate levels. Restricted Workspaces, Environments, and Chains will not be visible to these users. If they are provided a link to a Workspace, Environment, or Chain that they do not have access to, they will see the "Not Found" page.
Learn how to configure User Settings.