This article provides and overview of managing users and custom roles to limit your users' access to specific functionality within the application.
Users are given access to your AtomSphere account through Setup > User Management. You can create any number of users in your AtomSphere account. AtomSphere User Management is responsible for both authentication and authorization.
The actions a user is allowed to perform is controlled through role-based access. Roles are collections of privileges that control access to the various functionality within the application. AtomSphere provides several default roles for common sets of user responsibilities. Additionally you can create custom roles (requires Advanced User Security feature). Users may be assigned multiple roles in which case they receive the combined set of privileges.
Only users with a valid user ID can access your AtomSphere account. To manage users go to Account menu > Setup > User Management.
To create a user, click add and complete the form (all fields are required). Choose at least one role.
The user email address becomes the user ID. Shortly after the account is created, a user receives an email with login instructions to create a new password.
Managing Access via Single Sign On
Requires the Advanced User Security feature.
Users can be authenticated using an external identify provider such as LDAP by enabling and configuring Single Sign On (SSO) for your account.
There is very specific behavior around users who have access to multiple accounts. See Controlling User Access to Your Account for more information.
You can configure password policies to require user passwords to follow certain restrictions such as expiry period, minimum length, and formatting.
Go to Account menu > Setup > Password Policy.
See Password Policy Rules for more information.
Accessing Multiple AtomSphere Accounts
It is possible for a user to have access to multiple AtomSphere accounts. This is most common for partners that manage multiple customer accounts. Partner user access is also managed through Account Groups.
To grant access to multiple accounts, a user with the same email/user ID is created in each account's User Management. That user can then easily switch between accounts without logging in again by going to Account menu > Switch Account....
Note if password policies are enforced in any account to which a user has access, the user must create a password that conforms to the strictest policy.
See Controlling User Access to Your Account for more information.
Roles are collections of privileges that control access to the various functionality within the application. Users may be assigned one or more roles. Multiple roles are often used to grant the same user different levels of access across different environments (see Restricting Environment Access below). When a user has multiple roles, he will be granted the combination of permissions from all the roles, while respecting any environment-specific restrictions.
See Common Use Case for Custom Roles for a detailed example of how custom roles can be used to control access as part of the development life cycle.
Requires the Advanced User Security feature.
AtomSphere provides several default roles for common sets of responsibilities. In addition you can create custom roles with the specific combinations of privileges that best meet your application access and development life cycle responsibilities.
Some ideas for custom roles are:
Read-only Build tab access
Dashboard only access
Restrict View Data to a subset of production support users
You can create custom roles from scratch or augment an existing role by inheriting its privileges. To augment another role, choose an Inherits Role and choose the additional privileges as desired.
Privileges are the individual permissions that grant a user to access or perform actions in a specific area of the AtomSphere platform. Privileges have been defined by Dell Boomi at a level that allows for fine-tuning of custom roles. For example, you can restrict specific roles from viewing data on the Dell Boomi platform via the user interface. Or, you could restrict a role from having access to the Process Deployment privilege so a user cannot deploy changes. Similarly, you can control the access to the Build, Deploy and Manage tabs by adding or removing privileges.
In general, a user's privileges are additive across their roles, meaning that if a user has a "lower" privilege in one role and a "higher" privilege in another role, the user will have the higher privilege. For example:
- Role A has the Build Read Access privilege.
- Role B has the Build Read and Write Access privilege.
- A user is assigned both roles.
- The user will be able to read AND write components in the Build tab.
However privileges for actions that occur with the context of an Environment (e.g. deploy, atom management, process reporting, etc.) can apply differently per environment using Environment Role assignments as discussed below.
The privileges associated with the default roles cannot be modified.
See the full list of privileges for more information .
Restricting Environment Access
Requires the Environments feature.
It is a best practice to establish separation of duties and not allow all your account's users complete access to all environments. For example, developers should be able to access the Build tab, and deploy to and configure extensions for a “dev” environment/Atom, but should not be able to view or modify production environment/Atom. Similarly a production support user should be able to view execution results and perhaps re-run failed documents in the production environment, but should not have access to build or deploy processes.
This type of access control is configured by assigning role(s) to one or more environments within the Atom Management screen. A user's role(s) must be explicitly assigned to an environment to be able to access it. The actions a user can perform within the context of that environment is determined by the user's roles assigned to that environment.
Users whose role contain the Environment Management privilege can always access all environments.
Restricting roles to environments has implications in a number of areas of the application including:
Note that environment restrictions do not apply to the Build tab.
It is possible for a user to be assigned to multiple roles and for those roles to be assigned to different environments. In this situation, the actions a user can perform within a given environment will vary by environment.
For example, consider the following scenario:
A custom “Developer” role is created with privileges Build Read and Write, Deploy, Execute Process, and Process Reporting.
A custom “Production Support” role is created with privileges Process Reporting and Dashboard.
Environments "DEV" and "PROD" are created.
The "Developer” role is assigned to the “DEV” environment.
The “Production Support” role is assigned to the “PROD” environment.
- A user is assigned both the “Developer” and “Production Support” roles.
- The user will be able to do the following:
In Build, view and modify all components.
In Deploy, view and deploy to the DEV environment only.
In Dashboard, view the PROD environment only.
In Process Reporting, view execution history for both DEV and PROD but execute processes in DEV only.
For a more detailed discussion of how you can use custom roles and environment assignments for access control, see Common Use Case for Custom Roles.
Note: Be aware the Environment Management privilege grants the ability to view and modify all environments within the Atom Management screen. To only permit viewing and modifying of a specific environment, configure the role with only the Atom Management privilege instead.
See Roles within an environment for more information.
Restricting Folder Access in Build
Requires the Advanced User Security feature.
In the Build console, user access can be restricted per folder. The optional folder permissions configuration can limit the user roles allowed to edit components within that folder. It does not hide the folder from view or prevent viewing or copying components within the folder.
Consider using folder restrictions for the following situations to avoid inadvertent modification by general users:
Restrict folders containing common/reusable components especially connections to "lead developers"
Restrict folders containing template/example processes to "lead developers"
Restrict folders for different projects to the respective development teams
The user's role must have the "Build Read Access" and/or "Build read and write access" privilege to be able to view the Build console in general.
The user's role must have the "Build Read and Write Access" privilege to potentially be able to modify components. If it only has "Build Read Access" all components will be read only regardless of folder permissions.
If a folder has no role restrictions, any user with Build Read and Write Access privilege can view and modify components within that folder. This is the default permissions for new folders.
If a folder has role restrictions, only users with that role may modify components with that folder. The components will be read only for all other user roles.
Only users with the Administrator role can manage folder permissions. Administrators do not automatically have Write Access to restricted folders, however they can manage the permissions to grant themselves access.
Folder restrictions only apply to the Build tab Component Explorer and do not apply to other tabs including Deploy, Atom Management, and Process Reporting.