Common Use Case for Custom Roles

Document created by rich_patterson Employee on May 12, 2017Last modified by Adam Arrowsmith on Oct 3, 2017
Version 10Show Document
  • View in full screen mode

Overview 

This article provides a detailed example of how to configure Custom Roles using a scenario commonly found in organizations with multiple individuals and teams with varying responsibilities. The following approach should be considered a starting point and adapted to your needs as required.

 

For an overview of managing users, see Understanding User Management and Custom Roles. You may also be interested in Environment Strategy and Planning for additional ideas of how to leverage environments.

 

 

Identify Functions within the Organization

Within your organization, you may have team members performing the following functions (with some individuals perhaps performing more than one):

  • Platform Administrators
  • Development
  • Test and QA
  • Release Management
  • Production Support

 

Environments

For this scenario, we'll assume there are three Environments within AtomSphere, representing the different stages of the software development life cycle:

  • Development
  • Test
  • Production

 

Understanding the Default Administrator Role

The default Administrator role comes pre-defined within the account. Users assigned this role have unlimited access to all features within the account.

 

In smaller organizations where the Boomi Administrative team is relatively small, this single role may be sufficient. However in larger organizations, you may want to define more granular access and separate responsibilities. For example, you may chose to identify users that should have access to User Management, and another team that has the ability to change settings in Cloud Management. For this example, we will describe the more simple scenario, but please review the "Other Considerations" section below for more information.

 

Considerations when using Single Sign On (SSO)

The default Administrator role has important behavior to understand if your account is configured to use Single Sign On (SSO) to authenticate AtomSphere users against an external identify provider. Specifically, users assigned to the Administrator role do NOT use SSO. Non-admin users will be authenticated against your external identity provider, however admin users will continue to authenticate with their AtomSphere platform credentials.

 

In general but especially for accounts using SSO, it is strongly recommended to limit the number of users assigned to the default Administrator role, and insist that the majority of users log into the account via the identity provider. This provides an extra layer of security and audit capabilities.

 

We typically recommend creating a "service user" with a valid email address, which can be assigned to the default Administrator role. This way, in the event the identity provider is unavailable administrators can still use this login to access the platform. Again care should be taken to limit the number of individuals who have access to these credentials and to maintain the platform password per the security guidelines.

 

Configure the Custom Roles

Within Setup > User Management, create the following Custom Roles. Keep in mind individual users may be assigned to more than one role.

 

  • SSO_Admin - Recommended when SSO is enabled in the Account. In this example, we created this role inheriting from the Default Admin, but not all privileges may be necessary.
  • Release_Management - These users are responsible for deploying/promoting processes and other components to higher Environments, and for maintaining Schedules, Environment Extensions, and other Atom settings that are under CM control.
  • Prod_SupportThese are the users that respond to process level failures in the Production environment. They will need to be able to see the Production data associated with executions, and will need to be able to execute processes.
  • TestThe testing team will be responsible for monitoring the Test Environment, and just like with Production, they should be able to see files associated with executions, and should be able to run processes.
  • Dev - Developers who will build integrations and can deploy to the Dev environment, and can execute and monitor processes there. In the example below, developers can create processes and deploy to the Dev environment, but will not have access to change Environment Extensions or other Atom settings within the Dev environment. 
  • Production_Read_Only - This supplemental role can be granted to specific individuals to help with Production issues. They will be able to see execution history and logs for Production executions, but should not have access to view potentially sensitive documents.
  • Test_Read_Only - This supplemental role, can be granted to individuals to need access to Test execution history, but not to the data files associated with those executions.

 

Privileges

Configure the Privileges for each Role as follows.

PrivilegeRelease_ManagementProd_SupportTestDevProduction_Read_OnlyTest_Read_Only

SSO_Admin

(Inherited from default Admin)

Atom Managementxx
Account Administrationx
Atom Management Read Accessxxxxx
Build Read Accessxxxxx
Build Read and Write Accessxx
Process Deploymentxxx
Dashboardxxxxxxx
Executexxxx
Licensingxxxx
Schedulingxx
View Audit Logsxx
View Dataxxxx
View Resultsxxxxxxx
User Managementx

 

Environment Role Restrictions

Within Atom Management, assign the Roles to the associated Environments as follows:

EnvironmentProd_SupportProd_Read_OnlyRelease_ManagementTestTest_Read_OnlyDevSSO_Admin
Developmentxx
Testxxx
Productionxxx

 

IMPORTANT: If a given user has multiple roles and those roles are assigned to multiple Environments, remember the privileges are still additive: the privileges from the assigned roles apply to all assigned environments. Privileges are NOT restricted on a per-Environment basis. Keep this in mind when assigning multiple roles to individual users.

 

Note: Because the SSO_Admin role has the "Environment Management" privilege, there is no need to explicitly grant them permissions to the Environments above.

 

Summary

Configure Roles and Environments as described above in order maintain governance within the account. Provide users with the access they need for their individual responsibilities but tightly control access to sensitive production data.

Attachments

    Outcomes