Access Management: Phase One

Checkmarx One's Access Management has undergone significant improvements. The new approach offers more granular and precise control over user access and permissions, focusing on simplicity, usability, and intuitiveness. Users, groups, and clients can now be assigned to various resources, which will determine their hierarchical access levels within the system.

Resource levels

In Phase I of the Access Management rollout, the process involves associating users, groups, and clients with various resources and determining their hierarchical access levels within the system. Three resource levels are introduced: Tenant, Application, and Project. A user with manage-access permissions can link users, groups, and clients to various levels based on their access levels.

Note

In each Settings window shown below, the Roles column in the Authorization tab displays the roles assigned in the IAM module.

Tenant Level: Users assigned at the tenant level obtain access to all system components. Assigning users at the Tenant Level is carried out in the Account Settings section.

Application Level: In Application Settings, users, groups, and clients can be added to the application level. Users assigned at the application level gain access to all projects associated with that application.

Project Level: Under Project Settings, users, groups, and clients can be added to the project level. Users assigned at the project level have access only to the specified project.

Universal roles and privilege inheritance

In Phase 1 of the new Access Management, the administration of roles and permissions persists within the Identity and Access Management (IAM) module. This centralized module ensures that roles assigned to users are universal across the platform, aligning with the access granted to users in Checkmarx One.

Roles are not project-specific but rather platform-wide. Consider the scenario where a user is associated with Application A and assigned the role of ast-scanner. In this case, the user assumes this role universally across all projects associated with Application A.

For instance, if Application A comprises two projects, 1 and 2, the user’s ast-scanner role applies to both projects. In practical terms, this means the user has scanning privileges in Project 1 and Project 2. If a new project is created within Application A, the user automatically inherits scanning privileges in this new project as well.

Obsolescence of “if-in-group” roles

Previously, the if-in-group roles were used to restrict access to specific areas by granting certain permissions or access rights based on the user's membership in specific groups.

In the current context of Access Management, this approach to role enforcement has become obsolete.

In the new architecture, users, groups, and clients are directly associated with the resources such as tenants, applications, or projects, providing a simpler way of restricting group access according to the organization's needs.

Smooth transition and customer impact

The impact on customers during this transition is carefully considered:

Role Conversion: All roles with if-in-group are automatically converted to roles without if-in-group, rendering them obsolete. This change has no impact.
Group Association: Groups belonging to a project or application will be automatically associated with the respective project or application, resulting in no impact.
User Adjustment: Users without if-in-group roles will be moved to the Tenant level. Administrators can now associate these users with different applications and/or projects without causing any disruption.
Access Restoration: Users with if-in-group roles will regain access through their group association, ensuring a smooth transition with no impact.
API Consistency: Existing APIs remain unchanged, preserving compatibility and causing no impact. Additionally, new APIs have been introduced to associate new users and groups with resources.

In this section: