Skip to main content

Role-based access control (Preview) Hosted customers only

To manage user access to applications, projects, and organization settings in Contrast, set up resource groups, roles, and user access groups.

Note

This feature is supported for hosted customers only and is in preview mode. If you want to be an early adopter, contact Contrast support.

On-premises customers manage Contrast access by setting up organization users and access groups.

RbacOverview.png

Access control settings

Access control requires these settings:

  • Users: The list of Contrast users who you can add to user access groups.

  • Resource groups: These groups determine which applications, data, settings, scan projects, and organization settings users can access, depending on their assigned role.

    You can use built-in resource groups or create custom groups.

  • Roles: Roles define the actions that users have permissions to perform.

    You can use built-in roles or create custom roles.

    The built-in role, Organization administrator. lets you manage all user access groups, roles, and resource groups.

  • User access groups: These groups assign roles to users.

    You can use built-in user access groups or create custom user access groups.

Methods for managing access control

To manage access control, use either of these methods:

  • Contrast web interface

    The Contrast web interface provides an visual method for setting up and managing access control. This method requires an Organization Administrator or Organization Admin role.

  • Access control APIs

    The access control APIs are useful if you want to automate access control management or integrate it into existing systems. This method requires the PLATFORM_ORG_MANAGE permission.

    Read more about the access control APIs.

Naming standards and requirements

Names for resource groups, roles, and user access groups must be unique for each organization. For example, you can't create two roles with the name, MyAdmins.

Before you create custom roles or groups, consider developing a naming standard for all custom settings. Doing so will help make managing a large number of custom settings easier. One approach is to map the names of resource groups to the roles that you would associate with those groups. For example, if you create a resource group named Ecommerce, a good role name would be Ecommerce Developer. The users with this role are your developers working on ecommerce applications.

Naming requirements for all custom settings

  • Names can contain up to 50 alphanumeric characters.

  • Descriptions can contain up to 1,024 characters.

  • You can use special characters and spaces in names and descriptions.

  • Names are case insensitive.

    For example, ecommerce developers and Ecommerce Developers are considered to be the same name.

In this section: