Access Control User Management (v2.0 and up)
The subsequent pages describe managing Access Control for users:
Access Control - My Profile Tab (v2.0 and up)
After signing in to Access Control, from the General page, any user can access and utilize the My Profile feature for defining personal user details.
For a new user who has not yet any roles assigned, only the My Profile tab will appear after login.
Notice
From the Password page, login passwords can be changed by Application users only.(LDAP/SAML/domain users cannot change their passwords, as the passwords are managed by the LDAP/SAML/domain.)
![]() |
From the General page, populate (or edit) your profile details in at least all required fields (indicated by *), and then click Save. When editing, a confirmation message is displayed.

Notice
Fields that are automatically populated are Username (designated at login, this is also appears as the My Profile name), and the user’s pre-assigned Authentication Provider (Application or LDAP / SAML identity provider account name).
Interface texts will be translated to one of the following languages, according to the Locale selected:
English (United States)
English (United Kingdom)
French (France)
Japanese (Japan)
Korean (Korea)
Portuguese (Brazil)
Portuguese (Portugal)
Russian (Russia)
Chinese (Simplified, China)
Chinese (Traditional, Taiwan)
Spanish (Spain)
To change your login password, click Password. Enter the requested information in the fields, and then click Update Password.
Notice
The password must contain at least 8 characters total, that includes at least one special symbol, one lower case letter, and one upper case letter.
![]() |
Access Control - Teams Tab (v2.0 and up)
The Teams tab allows for managing the various levels of teams, including adding/deleting, renaming and structuring the hierarchal level of the organization’s teams, as well as assigning user-members to those teams.

In addition, LDAP Group Mapping can also be performed on the Teams tab, where you search (using group name) to map LDAP groups to the Access Control teams.
LDAP Group Mapping
This feature is available only if specific configuration criteria are met (see LDAP Group Mapping below for details).

CxServer Team
The first user logged in (the one with Administrator user permissions) is by default automatically assigned to CxServer – the highest, “root” level team.
There must always be at least one user in the CxServer team in order to manage all the other teams (this user has User Manager permissions)
A user in the CxServer team can remove the association to that team (remove membership), however there must first be at least one other user within the CxServer team.
Hierarchy Tree Team Search
In the Hierarchy tree, you can search for a specific team by any string contained within the team information.
Notice
A search can be performed from anywhere in the team name and not necessarily at the beginning. Note that the search is not case-sensitive.
The Hierarchy Tree is filtered as you type and the closest result is displayed as bold text. The number of filtered teams out of the total team count is displayed as part of the Hierarchy header above the search bar.

You can reset the filter by either clearing the search string, or by clicking the “x” on the right of the search bar.
Add, Delete and Rename Teams
In the Teams tab (Hierarchy pane), you can add/delete or rename teams.

Add a Team
Notice
When a user is assigned to a newly created team, the new team appears immediately for that user in the hierarchal structure. However, other changes will be seen only after logging out and then logging in again - for example, if a logged-in user is assigned to an additional team in a different hierarchy, the user will be able to see the additional team (in the Users tab) and its respective members (in the Teams tab > hierarchal tree structure) only at that point.
In the hierarchal tree structure, click on the level that will be the “parent” level to the team you are creating (the level directly above what you wish to create), then click and select Add Team.
Enter a team name in the dialog box using any character except backslash (\), forward slash (/) and dot(.), and then click Add Team. The newly added team name now appears in the hierarchal tree structure.
Delete a Team
Notice
The highest level team “CxServer” cannot be deleted or renamed.
If a team to be deleted contains any member(s) for whom it is their only team, the team cannot be deleted. In order to delete the team, those member(s) need to either be deleted or assigned another team.
Deleting a team will remove all LDAP group mappings connected to the team.
It is not possibleto delete a team which is used as a default team in an LDAP server or SAML IdP
In the hierarchal tree structure, click on the team to delete, then click and select Delete Team. A warning message notifies that if deleted, all LDAP group mappings for the team will be removed.
Click Delete on the dialog box to delete the team. A message informs that the team is deleted, and it no longer appears on the tree structure.
Rename a Team
A user can only rename teams that are at a level hierarchically lower than the team(s) the user belongs to, unless the user is also a member of the CxServer team (which by default is at the highest “root” level in the hierarchal tree structure) – in which case the user can rename virtually any team under CxServer.
Notice
The CxServer team cannot be renamed or deleted.
Examples (see illustration below):
A member of the Mgmt & Admin team can only change the name of the Security team and AppSec team – the teams nested directly under it
A member of Rene’s team cannot rename any team, as there is no team nested under it
A member of the CxServer team (highest level) can rename any other team (all of which are all nested under it).
![]() |
To rename a team:
In the hierarchal tree structure, click on the team to rename, then click and select Rename Team.
Enter (type over) a team name in the dialog box using any character except backslash (\), and then click Save. The renamed team name now appears in the tree.
Hierarchal Structuring of Teams
In the Teams tab (Hierarchy pane), the hierarchal nesting structure of the teams in the tree can be changed, with certain restrictions (see below).
Describing the Hierarchal Structuring of Teams
Moving a higher-level (‘parent-level’) team in the hierarchal tree structure will also move any respective teams that are nested under it (‘children-level’ teams), preserving the same parent–child nesting structure relationship of those teams.
A “group of teams” is defined as teams that have their highest hierarchal level positioned as ‘2nd-tier’ in the tree structure – meaning the level directly below CxServer (the highest “root” level in the entire hierarchal tree structure)
In the illustration above, ‘groups of teams’ are:
Open Source Team
Mgmt & Admin
R&D
Except for users with User Manager permissions that reside in the CxServer Team, no other user with User Manager permissions can move any other team (from a different group of teams of which the user is not a member) into a group of teams the user belongs to – in fact, the other teams will not even be visible.
Any user with User Manager permissions can however re-position another team (from within the same group of team/s the user belongs) to another level, as long as it is a level lower than that of the user’s team.
Examples for those with User Manager permissions who are not in the CxServer Team:
Within the Mgmt & Admin group of teams, AppSec team can be moved up to the same level as Security team, but it cannot be moved to the same level as (or higher than) Mgmt & Admin – the highest level in the group:
![]() |
Within the R&D group of teams, Brad’s team can be moved only under Rene’s Team or under Sonia’s Team:
![]() |
To move a team within the hierarchal structure:
While you left-click on a team, drag it to its new position (under another team). When dragging it, you may need to position it a bit to the right until you see a blue line, marking the position where you are repositioning the team. A confirmation prompt informs you where the team will be moved to.
Click Move on the confirmation prompt.
In the illustration below, the IAST Team is being moved from under New Platforms Team to a higher level (under R&D Team) – where it now will be the same level as the Open Source, UI and New Platforms teams:
![]() |
Add and Remove Team Members
In Teams tab > Members, you can add/delete members for any existing team (the user, however, will not be deleted).
Add Team Members
In the Hierarchy tree, click on the team that you want to assign member(s) to.
Click Add Member. Existing members of the team are displayed in the Add Team Member window.
Search by name using the Search Users field, or scroll through the list and select the checkboxes of members to add to the team.
![]() |
Click Add Members. The member(s) are added to the team:
![]() |
Remove Team Members
In the Hierarchy tree, click on the team from which you want to remove a member. All current members for the team are displayed.
In the Members window, click the Remove Member icon () of a member you want to remove from the team.
On the confirmation message, click Remove. A message confirms the removal.
LDAP Group Mapping
From the Teams tab you can perform LDAP Group Mapping, which allows for automatically mapping (assigning) users who belong to specific LDAP Groups to specific Access Control teams. This feature is available only if all of the following apply:
At least 1 configured LDAP server is active
Synchronization is enabled (see Access Control - Settings Tab > LDAP Settings – Synchronizatio n)
Advanced Team & Role Mapping is enabled (see Access Control - Settings Tab > LDAP Settings – Synchronizatio n)
User has permissions to manage Authentication Providers (Admin or Access Control Manager permissions)
![]() |
From Teams tab > LDAP Group Mapping tab, click Add LDAP Group Mapping. The Add LDAP Groups window is displayed.
![]() |
In the Directory field, click the arrow and select the directory that you will map the group(s) to.
In the Search LDAP Groups field, search for an LDAP group name by entering searchable text/characters, and then click or press Enter to display the results.
Notice
All characters are permitted in the search field, except for the backslash (\).
If an LDAP group name has already been mapped to the same directory, in the search result list it will appear as non-selectable (greyed) and labeled ‘mapped’:
![]() |
On the results list, select the LDAP group(s) to map to the directory, and then click the Add LDAP Groups button. The LDAP groups are mapped, and are displayed in the LDAP Group Mapping list.
Access Control - Users Tab (v2.0 and up)
From the Users tab you can do the following:
Search for and view all (or specific) users – with filtering capabilities
Add/delete users (also import LDAP / domain users from directory)
Modify user status (activate/deactivate)
Assign teams and roles
Reset password
Edit user data
Export a list of users
![]() |
The Users tab provides the following information columns/options:
Column | Description |
---|---|
Name | Users full name |
User name | User name as defined for login credentials |
Authentication Provider | The method used for authentication: Application, LDAP server (name of configured LDAP server) |
Users email address | |
Teams | This team(s) assigned to the user (at least one team per user). Multiple teams can be defined. You can also filter the users displayed in this list by teams (see Filter by User Column, below). NOTE: If multiple teams are assigned, a multiple team indicator |
Role | Lists the role(s) given to each user. You can also filter the users displayed in this list by roles (see Filter by User Column, below). NOTE: If multiple roles are assigned a multiple role indicator |
Last Login | This represents the last time the user logged into Access Control. You can filter the users displayed in this list by last login time frames (see Filter by User Column below). |
Search for Users
In the Users List, you can search for a specific user by any string contained within the user information. The list will be filtered as you type.
Notice
All fields are searchable except for filtered fields (Teams, Roles and Last Login).
Export Users List (.csv)
To export the full list of Access Control users to CSV format, click Export. The Access Control users.csv file is downloaded to your default download directory.
Filter By User Columns
You can filter certain columns (Teams, Roles and Last Login only) in the Users tab. Simply click on the filter icon, select the desired filtering option(s), and then click Filte r. The results are displayed.
You can search for a specific filtering option by entering searchable text in the Search For field.
In addition, you can click Select All (selects all checkboxes), Clear (clears all checkboxes), or Reset (reverts back to the default “not-selected” state). Then click Filter.
Examples of filtering options :
![]() |
![]() |
Add a New User
The Add New User dialog enables inputting not just the user’s personal details (manually, or by importing an existing user from an LDAP directory or Windows domain), but also respective user team(s) and role(s).
Notice
According to license limit, one or more users can be created for any Checkmarx product - each of whom must have at least one product-specific permission (which defines them as users for that product).
A CxSAST user is defined as having any CxSAST permission
An Auditor is defined as having the use-cxaudit permission
Add New User – General Tab
To add a new user to Access Control, click the Add User button. The Add New User window > General tab is displayed by default.
Fill in the required information for the General tab (see table below for details).
![]() |
The General tab provides the following information fields for user data:
Field | Description |
---|---|
First Name * | User’s first name |
Last Name * | User’s last name |
User Name * | User’s name as defined for login credentials. Backslash, forward slash (/, \) and dot (.) cannot be used in a username. NOTE: Only Application users can edit their user names. LDAP/SAML/domain users cannot edit their user names. |
Email * | User’s email address |
Job Title | Responsibilities of the user’s position or the level of the job |
Phone | User’s telephone number |
Mobile Phone | User’s mobile telephone number |
Country | Country where the user is located |
Other | Any other information |
Locale | User’s preferred language. The default language is English (United States). NOTE: Interface texts will be translated according to the locale that is selected. |
Password * | User’s unique password. Must be retyped to confirm. NOTE: Password must be at least 8 characters long and contain at least one special symbol, at least one lowercase letter, and at least one uppercase letter. NOTE: Login passwords can only be changed by Application users. The passwords of LDAP, SAML, and domain users are managed by the LDAP/SAML/domain. |
Retype Password | Re-enter password |
Expiration Date | Click in the field to set the date after which the user should be automatically deactivated. NOTE: Only Application users have expiration dates (required even for those with User Manager permissions). The expiration date field will be disabled for LDAP, SAML and domain users as they are managed externally by the directory/IdP servers. |
Activate User | All new users are activated, by default. You can deactivate the user by using the toggle option (see Deactivate a User, below). |
* indicates required field
Add LDAP User – General Tab
For LDAP users only:
An administrator cannot reset an LDAP user’s password, as it is determined only by the LDAP Server.
An LDAP user cannot use the "Forgot password" link
An LDAP user cannot change the User name or Expiration Date fields
Import New LDAP Users from Directory
The Import from Directory link appears on each of the three tabs in the Add New User window whenever there is at least one active LDAP or domain server configured.
When creating new LDAP users, this enables you to add (by importing from the directory) new user details manually – one user at a time, which populates the following user-detail fields in the Add New User window:
User name
First name
Last name
Email address
To import a new LDAP user from directory:
From the Add New User window – General tab, click the Import from Directory link. The Import Directory User Details window is displayed.
In the Directory field, click the arrow and then select a directory.
![]() |
In the search field you can search the selected directory for the username by entering, for example, a username, a part of a username or uniquely-identifying alphanumeric characters (from which the username is comprised), and then click to display the results:
![]() |
For each displayed result that you wish to import, hover the cursor over it and then click its Import button. The user’s details now appear in its Add New User window. Scroll to each field making sure all required information is entered. See Add New User, above.
Importing Domain Users from Directory
Notice
A domain user can be created who is only associated with a domain that's unmapped to LDAP SSO.
The Import from Directory link appears on the Add New User window – General tab only when there is at least one active LDAP or domain server configured.
When importing Domain users, this feature enables you to add (by importing from the directory) new user details manually – one user at a time, which populates the following user-detail fields in the Add New User window:
User name
First name
Last name
Email address
To import a new domain user from directory:
From the Add New User window – General tab, click the Import from Directory link. The Import Directory User Details window is displayed.
In the Directory field, click the arrow and then select a directory.
![]() |
In the search field you can search the selected directory for the username by entering, for example, a username, a part of a username or uniquely-identifying characters (from which the user name is comprised), and then click to display the results:
![]() |
For each displayed result that you wish to import, hover the cursor over it and then click its Import button. The user’s details now appear in its Add New User window. Scroll to each field making sure all required information is entered. See Add New User, above.
Deactivate / Activate a User

All new users are activated by default. In the Add New User dialog use the toggle option to deactivate / activate the user as needed, and confirm the change by clicking Save.
Notice
Deactivated users will not be able to sign in.
On the list of users (User’s tab), deactivated users are indicated with a red icon:

Users can also be deactivated via the LDAP Server settings, where a periodically-performed sync (if enabled) deactivates all deleted LDAP users (see Access Control - Settings Tab > LDAP Settings – Synchronization)
Notice
Deactivated users can be reactivated at any point.
Saving Information in the General Tab
In the Add New User window, when finished with the General tab, click Save. A message will prompt you to go on to the next (Teams) tab to complete.
Notice
In the Add New User window, both the General and Teams tabs are mandatory. The Roles tab is optional.
Add a New User – Teams Tab
Assign Teams to New Users
Notice
It is mandatory that each user is assigned to at least one team.
From the Add New User – Teams tab you assign team(s) to the new user by clicking the relevant checkboxes.
When finished with the Teams tab, click Save. A message will prompt you to go on to the next (optional) Roles tab to complete.

Add a New User – Roles Tab
Notice
Access Control does not support default roles for new users. Each new user will need to be manually assigned roles.
Add Roles to New Users
From the Add New User > Roles tab, assign role(s) to a user by clicking the relevant checkboxes.
When finished with the Roles tab, click Save. If you have already completed the required General and Teams tabs, the newly created user will appear in the Access Control > Users list.
![]() |
The Add New User window > Roles tab displays all roles, whether user-created or provided.
Notice
The roles that display will be relevant for the Checkmarx product(s) installed.
The following table lists the predefined roles that are provided when using CxSAST or CxOSA:
Notice
These predefined (provided) roles cannot be updated or deleted.
Provided Roles for CxSAST / CxOSA | Type | Description |
---|---|---|
Admin | Access Control | The Checkmarx products global administrator. Complete, all-inclusive set of permissions for all tasks. |
Access Control Manager | Access Control | Manages users, authentication and system settings |
User Manager | Access Control | Manages the users in the system |
Scanner | CxSAST, CxOSA | Permissions to create and manage projects, and run scans |
Reviewer | CxSAST, CxOSA | "Read only" permissions to view scan results and generate reports |
Auditor | CxSAST only | Permissions to manage vulnerability queries and use CxAudit |
Results Updater | CxSAST, CxOSA | Permissions to update the properties of scan results |
Results Verifier | CxSAST, CxOSA | Permissions to set the state of scan results to "Not Exploitable" |
Data Cleaner | CxSAST only | Permissions to delete projects and scans |
SAST Admin | CxSAST, CxOSA | Full permissions |
The following roles are relevant for CxSAST/CxOSA only if Management and Orchestration is installed:
Provided Roles for CxSAST / CxOSA | Type | Description |
---|---|---|
Security Risk Manager | Management & Orchestration | The following permissions that allow for managing the organization’s security risk at scale, manage policies, KPIs, business application, risk weight and more:
|
Security Risk Viewer | Management & Orchestration | The following permission that allows for tracking the security risk, viewing policies violations and KPIs:
|
Edit User
Edit an Existing User’s Details
From the Users tab, to edit an existing user’s details, click its menu and then select Edit User.
![]() |
From the Edit User window that is displayed, make your changes on each of the 3 tabs (General, Teams, Roles) as needed.
Notice
From the Edit User window, the General and Teams tabs are mandatory, while the Roles tab is optional.
Interface texts will be translated according to the locale that is selected.
Click Save on the last tab edited (this will save changes on all tabs edited). The user’s details are saved and any new changes are displayed on the Users List page.
![]() |
Deactivate / Activatea User

All new users are activated by default. In the Edit User dialog use the toggle option to deactivate / activate the user as needed, and confirm the change by clicking Save.
On the list of users (User’s tab), deactivated users are indicated with a red icon:

Users can also be deactivated via the LDAP Server settings, where a periodically-performed sync (if enabled) deactivates all deleted LDAP users (see Access Control - Settings Tab > LDAP Settings – Synchronization).
Notice
Deactivated users can be reactivated at any point.
Reset Password
Reset an Existing User Password
Reset Password
Only Applications users can have their passwords reset.
In order to reset an existing user’s password, the SMTP server must be configured in the system. If not, the user must contact the system-responsible person (such as a Checkmarx Administrator or User Manager) who will provide the user with a temporary password, which is changeable after signing in with it the first time.
Once you reset a password, it cannot be undone.
To reset an existing user’s password, click the user’s icon and select Reset Password from the dropdown menu. The Confirm Password Reset dialog is displayed.
To proceed, click Reset Password. Another message is displayed which provides a temporary password for the user’s initial login.
You will need to send the user this temporary password, so make a note of it (or you can click Copy to save it to the clipboard), and then click to close the message window.
Send the user the temporary password, and instruct the user to sign in to Access Control using that temporary password, and then change the password as follows:
Enter the temporary password.
Change the temporary password to one with a minimum of 8 characters, which includes at least 1 in uppercase, at least 1 non-alphanumeric character, and at least 1 digit.
Click Update Password.
![]() |
Delete User
Notice
Once you delete a user, it cannot be undone.
To delete a user (other than yourself), click the user’s menu and then select Delete User.
On the confirmation message that displays, click Delete. The user is deleted from Access Control and is no longer displayed in the Users List page.
Access Control - Roles Tab (v2.0 and up)
From the Roles tab, you can do the following:
Create roles
Edit roles
Duplicate roles
View all existing roles – user-created, and the predefined, provided roles
Search for specific roles – by entering a partial or full name in the Search for Roles field
Choose the number of roles to view at a time in the window
![]() |
Roles
The roles that display will be relevant for the Checkmarx product(s) installed.
The predefined roles provided by the system cannot be updated or deleted.
A mapped role in the LDAP server / SAML IdP cannot be deleted.
Access Control does not support default roles for new users. Each new user will need to be manually assigned role(s).
For information on predefined, provided CxSAST / CxOSA roles and permissions, see here.
The following table lists the predefined roles that are provided when using CxSAST or CxOSA:
Provided Roles for CxSAST / CxOSA | Type | Description |
---|---|---|
Admin | Access Control | The Checkmarx products global administrator. Complete, all-inclusive set of permissions for all tasks. |
Access Control Manager | Access Control | Manages users, authentication, system settings |
User Manager | Access Control | Manages the users in the system NoticeA User Manager can assign to itself or to other user roles, regardless of their defined user permissions. In this respect, the User Manager acts as the Admin. |
Scanner | CxSAST, CxOSA | Permissions to create and manage projects, and run scans |
Reviewer | CxSAST, CxOSA | "Read only" permissions to view scan results and generate reports |
Auditor | CxSAST only | Permissions to manage vulnerability queries and use CxAudit |
Results Updater | CxSAST, CxOSA | Permissions to update the properties of scan results |
Results Verifier | CxSAST, CxOSA | Permissions to set the state of scan results to "Not Exploitable" |
Data Cleaner | CxSAST only | Permissions to delete projects and scans |
SAST Admin | CxSAST, CxOSA | Full permissions |
The following roles are relevant for CxSAST/CxOSA only if Management and Orchestration is installed:
Provided Roles for CxSAST / CxOSA | Type | Description |
---|---|---|
Security Risk Manager | Management & Orchestration | The following permissions that allow for managing the organization’s security risk at scale, manage policies, KPIs, business application, risk weight and more:
|
Security Risk Viewer | Management & Orchestration | The following permission that allows for tracking the security risk, viewing policies violations and KPIs:
|
Create a New Role
From the Roles tab, click New Role. The Role window is displayed, where you create a new role by assigning a name and description, and selecting all relevant permissions (for purposes of access control).
New Roles
When a user is assigned to a newly created role, the role appears immediately for that user in the Users tab. However, other changes will be seen only after the user assigned the new role logs out and then logs in again – for example, the Settings tab (for those with Access Control Manager permissions) will appear only at that point.
![]() |
Enter a name in the Role Name field, and a description in the Description field.
Click to expand and view the list of all permissions in a category and its sub-categories (in the example below, the category is Management and Orchestration and the sub-category is Security risk management). Click again to collapse the list.
Select checkboxes of all relevant permissions for which this role will be associated as follows:
Select a sub-category checkbox to include all permissions in that sub-category.
Click Select All to select all permissions in the entire category.
Click Clear All to clear all selected permissions in the entire category.
Select individual checkboxes of specific permissions.
![]() |
Click Save. A message indicates the successful role creation, and the newly created role is displayed in the listing of roles.
![]() |
Edit a Role
Editing a user-created role should be done with caution. This is to help safeguard from erroneously modifying the attributes of a role that is currently in use, or that may need to be used “as is” in the future. For the same reasons, the predefined roles that are provided by the system cannot be updated (edited) nor deleted.
Editing a Role
Any changes performed to a role (adding or removing permissions) will only take effect after the assigned user logs-out and re-logs into the system, or once the access token is renewed (default=every 1 hour).
In order to easily adapt any existing role with the changes you need, instead of editing it, first duplicate it – and then make whatever changes are necessary to the duplicated role, including a unique name. See Duplicate a Role, below.
Notice
The Admin role cannot be edited. This role inherits all permissions in the system.
From the Roles tab, to edit an existing role, click the respective menu and then select Edit.
![]() |
The Role window is displayed, where you can edit an existing role’s name, description, as well as the relevant permissions for access control purposes.
![]() |
Type over a role’s name or description in the respective fields in order to edit it.
Click to expand and view the list of all permissions in a category and its sub-categories (in the example below, the category is Management and Orchestration and the sub-category is Security risk management). Click again to collapse the list.
Select (or clear) checkboxes to change the relevant permissions for which the role will be associated as follows:
Select a sub-category checkbox to include all permissions in that sub-category.
Click Select All to select all permissions in the entire category.
Click Clear All to clear all selected permissions in the entire category.
Select individual checkboxes of specific permissions.
![]() |
Click Save. A message indicates the successful update, and the newly edited role is displayed in the listing of roles.
![]() |
Duplicate a Role
If you need to create a new role with similar attributes to any existing role – whether it’s a user-created role or a non-editable provided role, you can duplicate the existing role and then modify it further, as necessary – including assigning it a unique name (mandatory).
This streamlines the process in creating a new role, and it helps safeguard from erroneously modifying an existing role that is currently associated with other users, or that may need to be sometime in the future used “as is. “
From the Roles tab, to duplicate an existing role, click the respective menu and then select Duplicate.
Notice
The Admin role cannot be deleted or edited as it inherits all permissions in the system – but it can be duplicated.
![]() |
The Role window is displayed, where the duplicated role displays, prefaced with “Copy of…”
Change the existing role’s name to a unique name, and provide a description. You can also change the relevant permissions for access control purposes.
![]() |
Type over a role’s name and description in the respective fields to change it.
Click to expand and view the list of all permissions in a category and its sub-categories (in the example below, the category is Management and Orchestration and the sub-category is Security risk management). Click again to collapse the list.
Select (or clear) checkboxes to change the relevant permissions for which the role will be associated as follows:
Select a sub-category checkbox to include all permissions in that sub-category.
Click Select All to select all permissions in the entire category.
Click Clear All to clear all selected permissions in the entire category.
Select individual checkboxes of specific permissions.
![]() |
Delete a Role
Notice
Predefined roles provided by the system cannot be updated or deleted.
From the Roles tab, to delete a role, click the respective menu and then select Delete.
On the confirmation message that displays, click Delete.
Access Control - Settings Tab (v2.0 and up)
The Settings tab enables the Access Control Admin or Access Control Manager user to set up and define general settings for SMTP and Domain Management, as well as settings for LDAP and SAML.
This section contains the following pages:
Settings Tab - General Settings (v2.0 and up)
General Settings allows the Access Control Admin or Access Control Manager user to set up and define the system’s general settings for SMTP and Domain Management.
To enter the Settings page, click the Settings tab. The General Settings page is displayed.
![]() |
Configuring General Settings (General Tab)
On the General Settings page, you can configure the following:
SMTP Server settings
Domain Management settings
SMTP Server Settings
The SMTP Server can email administrators about access control changes and alerts. First, however, you need to configure the SMTP settings that the server uses to send these emails.
Notice
Users cannot reset their own password using the ‘Forgot Password’ option if the SMTP server is not configured.
For post-migration to access control 2.0 there will be two places to configure SMTP settings:
For access control for 'Forgot Password' use cases.
For SAST return emails, see General Settings>SMTP Settings in Application Settings
The General Settings page – SMTP Settings section provides the following information fields/options.
Field | Description | |
---|---|---|
Host (Outgoing Mail Server) * | Enter the name or IP address of the outgoing mail server. | |
Port * | If you are not using the default SMTP port 25 (if encryption is not used), you can change the SMTP port value. | |
Encryption Type | SSL – Enable SSL to ensure that the connection to your mail server is encrypted and secure. TLS – Enable TLS for a more advanced and secure version of SSL. None – to connect to your mail server without encryption | |
Send from address * | Enter the address that will send the email (e.g., [email protected]). | |
User default credentials | Check to use the default credentials. | |
User Name and Password | Optionally, enter the SMTP user name and password for your pre-configured SMTP server account. | |
Send Test Email | Once the settings are defined, use this option to validate the connection. Validation is performed by sending and receiving a test email.
|
* indicates required field
Enter all the required information, and then click Send a Test Email to ensure SMTP connectivity. A message informs you of the test status.
Upon notification of a successful email test, click Update to save the settings.
![]() |
Domain Management Settings
Used for LDAP-enabled SSO login and user authentication, from the Domain Management settings you manage existing and new domains.
The General Settings page – Domain Management section provides the following information fields/options.
Field | Description | |
---|---|---|
Domain Name | The (short) domain name | |
DNS Domain | The Fully Qualified Domain Name (FDQN) | |
Add | Click to add a new domain. | |
Name* | Enter the short domain name, which can be determined by running “Echo %userdomain%” in the command prompt. | |
DNS Domain* | Enter the Fully Qualified Domain Name (FDQN), which can be determined by running "echo %userDNSdomain%" in the command prompt. | |
| For editing the domain. Click the icon and edit as needed, then click UPDATE. | |
| For removing the domain. Click the icon, then on the confirmation message click REMOVE. |
* indicates a required field
![]() |
Settings Tab - LDAP Server Settings (v2.0 and up)
LDAP Server Settings allows for the Access Control Admin or Access Control Manager user to set up and define settings for LDAP servers.
Configuring LDAP Server Settings (LDAP Page)
LDAP (Lightweight Directory Access Protocol) is an Internet protocol that Web applications can use to look up information about users and groups from the LDAP server – such as information pertaining to authentication, authorization, group and role mapping. Connecting to an LDAP directory server is useful if user groups are stored in a corporate directory. Synchronization with LDAP allows for the automatic creation, update and deletion of users and groups in the Checkmarx product, according to any changes being made in the LDAP directory.
You can configure one or more LDAP servers in the system.
Configuring a New LDAP Server
To configure a new LDAP server, go to the Settings tab > LDAP (LDAP Settings) page.
![]() |
Click Add New LDAP Server. The LDAP Servers > Server Settings tab is displayed.
Notice
Three tabs can be configured for the LDAP server: Server Settings, Directory Settings (required) and Synchronization (optional, disabled by default). Each tab displays the default (but changeable) attributes in its respective fields – according to the directory type selected.
LDAP Settings – Server Settings Tab
The first of three tabs to configure on the LDAP Servers page is Server Settings, where you configure the LDAP server connection settings.
![]() |
The LDAP Settings > Server Settings page provides the following information fields/options.
Field | Description |
---|---|
Enable LDAP Server | Toggle to enable/disable the LDAP server. NOTE: Disabling the LDAP server will prevent the users of this LDAP server from logging into the system. It will still be possible to manually add users and map LDAP groups to roles. |
Server name * | Enter the name of the LDAP server. NOTE: This name that will also be used in the login page. |
Host name * | Enter the LDAP server hostname For exampl e: ldap.company.com |
Port * | Enter the LDAP server port For example: 389, 636 (for SSL) |
User name & Password * | Enter the credentials of the binding user (LDAP bind username and bind password). NOTE: User needs at least read permissions to the LDAP directory. The username can be in the following formats: <domain\username> or <[email protected]> or <full user DN> For example: [email protected] or cn=user,dc=domain,dc=name |
Use SSL | Check this to connect to the LDAP server using SSL encryption |
Verify SSL certificate | Check this to verify the SSL certificate. NOTE: If you are using an untrusted certificate, you can cancel the verification of certificate to make the connection pass. SSL will still be used and the network will be encrypted. |
* indicates required field
After all information is entered, click Test Connection to validate the LDAP connectivity. A message informs you of the test status.
Upon a successful connectivity test, click Save, and then configure in Directory Settings.
LDAP Settings – Directory Settings Tab
The second tab to configure on the LDAP Servers page is Directory Settings.
Example of Directory Settings page, for the directory type Active Directory:
![]() |
The following is an example of Directory Settings page, for the directory type Open LDAP:
![]() |
The LDAP Settings > Directory Settings page provides the following information fields/options.
Field | Description |
---|---|
Directory Type * | Select from the options: Active Directory, Open LDAP, Custom LDAP Server. Server attributes are automatically populated according to default settings. |
Enable SSO | NOTES:
|
Domain * | Select a Windows domain to map the LDAP server to. NOTES:
|
Base DN * | The LDAP root node for searching users. |
Additional User DN | Limits user search to specific DN (in order to optimize the search time). The additional user DN is appended to the base DN. NOTE: Do not repeat the base DN in this field. |
User Object Class * | The LDAP user object class type to use when loading users. |
User Object Filter * | The filter expression to use when searching user objects. |
Username Attribute * | The attribute field to use on the user object |
User First Name Attribute * | The attribute field to use when loading the user’s first name. |
User Last Name Attribute * | The attribute field to use when loading the user’s last name. |
User Email Attribute * | The attribute field to use when loading the user’s email |
* indicates required field
After all information is entered, click Test User Schema to check the connection to the LDAP server, and validate the user schema settings and attributes. A message informs of the test status.
Upon a successful user schema test, click Save and then configure in Synchronization .
LDAP Settings – Synchronization Tab
The third tab to configure on the LDAP Servers page is Synchronization.
![]() |
Notice
The "Enable Default Team" and "Enable Default Role" capabilities are available only from CxSAST 9.0 HF8
Field | Description |
---|---|
Synchronization enabled/disabled | If synchronization is disabled, users will need to be created manually (via Import from Directory only), as there is no information about role and team in order to create them. Enabling synchronization enables automatically creating new LDAP users who will be automatically assigned to roles and teams, according to their LDAP mapping. NOTE: If synchronization is disabled, login can only be performed only using existing LDAP users. If synchronization is enabled, a user can easily login with only user name and password. |
ROLE AND TEAM MAPPING | |
Enables defining the default role(s) and team(s) to be assigned to newly-created LDAP-based users. | |
Default Role & Default Team * | Define the default role and team that will be assigned to newly-created, LDAP-based users. NOTE: A default team (but not a default role) must be selected when synchronization is enabled. In the Hierarchy tree, you can search for a specific team by any string contained within the team information (see Hierarchy Tree Team Search). These defaults (for Role and Team) will be used in case no Advanced Team and Role Mapping were defined for a current user trying to login. |
Automatically update user role and team upon login | If checked, a user’s role and team will be automatically updated upon login, according to default or Advanced Team and Role Mapping. NOTE: If this feature is not checked, a user's personal details will only be updated once – at the first login. |
Periodically sync user availability | If checked, then every 24-hours all LDAP users (usernames) that were deleted from the LDAP server will be deactivated in Access Control (therefore freeing up those licenses). A red indicator next to a user’s name (on the list of users – User’s tab) indicates the user has been deactivated: ![]() NOTE: If the connection to the LDAP server fails, the deleted users will not be deactivated in Access Control. |
Advanced Team and Role Mapping | Enables mapping roles and teams to LDAP groups. Enables a user’s role to be automatically set according to specific LDAP group DNs. Enables the user to automatically be assigned to a team according to LDAP mapping configuration (see Access Control - Teams Tab > LDAP Group Mapping). |
Enable Default Team | When advanced Team and Role Mapping is enabled – enables or disables Default team mapping |
Enable Default Role | When advanced Team and Role Mapping is enabled – enables or disables Default role mapping |
GROUP SCHEMA SETTINGS | |
Enables defining the search of LDAP groups that can be mapped to teams (see Access Control - Teams Tab > LDAP Group Mapping). | |
Additional Group DN | [Optional]: The Additional Group DN (appended to the Base DN) reduces the search scope to a specific DN when searching for groups. NOTE: Do not repeat the Base DN in this field. |
Group Object Class | Used for team mapping, it defines the group object class, and limits group searching to a specific DN. NOTE: Required if Synchronization and Advanced Team and Role Mapping are enabled. |
Group Object Filter | Used for team mapping, Group Object Filter is an LDAP filter expression for use when searching groups. NOTE: Required if Synchronization and Advanced Team and Role Mapping are enabled. |
Group Name Attribute | Used for team mapping, Group Name Attribute is an attribute in LDAP defining a group’s name. NOTE: Required if Synchronization and Advanced Team and Role Mapping are enabled. |
MEMBERSHIP SCHEMA SETTINGS | |
Enables defining the attributes that associate the LDAP users with their assigned teams. | |
Group Members Attribute (member) | An LDAP member attribute which is multi-value, it contains a list of unique names for users in the team (user DNs), as well as group and contact objects that are members of the group. It is used to determine the logged in user groups, in order to perform the right mapping to roles and teams. NOTE: Required if Synchronization and Advanced Team and Role Mapping are enabled. |
User Membership Attribute (memberOf) | An LDAP memberOf attribute which is multi-value, it contains all the groups that the current user is a member of (group DNs). If designated, this attribute replaces the Group Members Attribute for determining the logged in user groups (taking the groups the user belongs to straight from the user entry, instead of searching inside every group). |
ADVANCED ROLE MAPPING | |
Define what role(s) the users in specific LDAP group(s) will be assigned (mapped) to. Multiple roles can be assigned to the same LDAP Group DN. 1. Click Edit Advanced Role Mapping. 2. Click the arrow in the Cx Role field and then select a role from the options. 3. In the LDAP Group DN field, use a semicolon to separate multiple group entries. Examples: cn=dev;ou=grp;dc=my;dc=org;cn=qa;ou=grp;dc=my;dc=org 4. Repeat this procedure for each LDAP group—role mapping. 5. Click Update. |
* indicates required field
After you have finished configuring synchronization settings (or if you have disabled synchronization), click Test User & Group Schema to check the connection to the LDAP server, validate the user schema settings and attributes, and validate the group. A message informs of the test status.
Click Save.
Editing an LDAP Server Configuration
To edit an existing LDAP server configuration, go to the Settings tab > LDAP (LDAP Settings) page.
![]() |
Click EDIT. The LDAP Servers > Server Settings tab is displayed.
Edit as needed in any of the three tabs: Server Settings, Directory Settings, Synchronization.
Be sure to test the connection, user schema, and user & group schema as applicable, and click SAVE on every tab that has been edited. See Configuring a New LDAP Server, above.
![]() |
Deleting an LDAP Server Configuration
Danger
Deleting an LDAP server configuration will remove all associated user data.
To delete an existing LDAP server configuration, go to the Settings tab > LDAP (LDAP Settings) page.
![]() |
For the LDAP server configuration you want to delete, click its delete icon , and then on the confirmation message click DELETE.
Creating LDAP Users in CxSAST
After configuring the LDAP server with SAST, you can import LDAP users into SAST.
Go to the Users tab.
Click Add User.
On the pop up, click Import From Directory.
Search for the user that you want to import from the LDAP directory and the press Enter.
Login using LDAP Single Sign-on
Login using LDAP single sign-on can be performed from the CxSAST web interface as follows:
Access the CxSAST web interface by using the Checkmarx Portal shortcut on the Desktop or navigate to the Checkmarx folder.
On the Login screen, for the Sign in method, select LDAP.
![]() |
NOTE- The LDAP Login option is only available in the CxSAST Login screen if LDAP is enabled in the LDAP configuration (Access Control > Settings > LDAP > LDAP Servers > Server Settings> Enable LDAP Server).
![]() |
Settings Tab - SAML Settings (v2.0 and up)
SAML Settings allows for the Access Control Admin or Access Control Manager user to set up and define settings for SAML.
Configuring SAML Settings (SAML Page)
Security Assertion Markup Language (SAML) is an XML-based format for the exchange of user authentication and authorization data between SAML Identity Provider/s (IdP) and a SAML Service Provider. CxSAST has just become SAML 2.0 aware and can now be configured to act as a SAML 2.0 Service Provider. SAML supports the user lifecycle by retrieving users from the Identity Provider and defining them in CxSAST. SAML is used for Single-Sign-On (SSO), is configurable for team & role mapping, and allows for more centralized and enhanced user management.
Configure one or more SAML identity providers (IdPs) in the system.
To configure SAML, go to the Settings tab > SAML (SAML Settings) page:
![]() |
Notice
For additional information on SAML configuration (for v9.0.0 and up), such as SAML Service Provider settings, SAML Identity Provider settings and SAML Single Sign-On with OKTA, see Single sign-on with OKTA and SAML.
SAML Settings – Identity Providers
The first of two SAML Settings tabs to configure is Identity Providers.
Click the Add Identity Providers link. The Add New SAML Provider page is displayed, where you can configure one or more identity providers in the system.
![]() |
The Identity Providers page provides the following information fields/options for configuring a new SAML IdP:
Field | Description |
---|---|
ADD NEW / EDIT SAML IDENTITY PROVIDER (IdP) | |
Configure one or more new SAML identity providers in the system. SAML will be used as a single sign-on login and can be configured for user authentication, team and role mapping. | |
Enable SAML | Toggle to enable/disable SAML |
Identity provider display name | Enter the display name of the SAML IdP server. Example: CxSAML |
Issuer (identity provider) | The unique identifier of the IdP, which is usually contained in the URL of the IdP. In certain SAML implementations, it is referred to as “entity Id.” This parameter is provided by the IdP setup information under ‘Identity Provider Issuer’. Example:https://srvl.idpname.com/mypageUnlink |
Single Sign-On URL | The IdP login location to where SAML requests will be sent. This parameter is provided by the IdP setup information under ‘Identity Provider Single Sign-On URL’. Example:https://srvl.idpname.com/app/checkmarxdev/sso/saml |
Logout Redirect URL | The location to where logout instances will be redirected. Example:https://srvl.idpname.com/apps |
Error Redirect URL | The location to where error instances will be redirected. |
IdP Certificate File | This is the public key (X.509 certificate) provided from the IdP Setup instructions under ‘Download Certificate’. The certificate will be used to validate the SAML assertion from the IdP. |
Browse | Browse for IdP certificate file location and navigate to the IdP certificate file (.cert) that was downloaded from the Identity Provider Setup instructions. |
Sign SAML AuthnRequest | Select to sign the SAML AuthnRequest |
Request Binding | Click the Request Binding dropdown arrow and select the SAML binding protocol to use when sending the request: HTTP-Redirect or HTTP-Post |
USER AUTHORIZATION MANAGEMENT | |
Presents two options to select from – if the user authorization teams and roles will be controlled by the SAML Identity Provider, or by the Access Control Application. | |
Application Authorization | By selecting this option, SAML users will be getting the default role and default team (as defined in the Default Role and Default Team fields) |
Default Role | Click the dropdown arrow, and select the default role to be assigned to newly created SAML-based users. |
Default Team | Click the SELECT button, and then click on a team name in the window that displays. Then click SELECT TEAM. |
IdP Authorization | By selecting this option, teams and roles managed by the SAML Identity Provider are automatically updated upon login to CxSAST/CxOSA. The definitions for the update are defined during the creation and mapping of user attributes in the SAML IdP. When the IdP Authorization option is selected, upon user login all the teams and roles that are manually assigned within Access Control (via the Application Authorization option) will be overwritten with the SAML-defined teams and roles. NOTE: The teams and roles assigned per user in the SAML IdP must exist in CxSAST prior to the assignment, otherwise the user won’t be assigned those teams/roles, and the user won't be able to log in to Checkmarx products. |
Click SAVE.
Notice
For additional information on SAML configuration (for v9.0.0 and up), such as SAML Identity Provider settings with OKTA, see Adding a New SAML Identity Provider in Access Control.
Editing a SAML Identity Provider Configuration
From the SAML Settings page, click EDIT on an existing SAML IdP configuration that needs editing. The Edit SAML Identity Provider window is displayed.
Edit the fields/options as needed (see the table above), and then click SAVE.
SAML Settings – Service Providers
The second of two SAML Settings tabs to configure is Service Provider.
A SAML service provider is a system entity (Checkmarx product such as CxSAST) that issues authentication assertions in conjunction with a Single Sign-On (SSO) profile of SAML.
![]() |
The Service Provider page provides the following information fields/options:
Field | Description |
---|---|
SP Certificate File | The certificate that will be used to sign the SAML request (default provided). |
Browse | You can browse to another SP Certificate file – but only upload P12 or PFX certification file formats that contain a private key. |
Password | The SP Certificate file password. |
Issuer (Service provider) | The unique identifier of the Service Provider (e.g., http{s}://{server}:{port}). The field must contain a valid fully-qualified HTTP or HTTPS URL. NOTE: The provided default value can be changed. |
Download Metadata | For downloading the Access Control SP metadata configuration. This file (Cx_SAML_Metadata) can be uploaded to the IdP for easier configuration of the Access Control SP. |
Click UPDATE.
Notice
For additional information on SAML configuration (for v9.0.0 and up), such as SAML Service Provider settings, see, Defining SAML Service Provider Settings in Access Control.
.
Access Control - Tracking User Actions (v2.0 and up)
Access Control provides the AuditTrail database table. The AuditTrail database table provides an audit log that can be used to track user actions. This table resides in the new CxDB schema under 'accesscontrol': [CxDB].[accesscontrol].[AuditTrail].

A typical use case example for using the audit log is if a user is suddenly denied access and can’t log in, you can look at the audit log to see who disabled the user, and when. Another use case example is if a user is moved from one team to another for an unknown reason, you can see who moved the user, and when.
The following user actions are audited in the AuditTrail database table:
Type | Action |
---|---|
UserCreated | User created |
UserUpdated | User updated (update doesn't include 'roles added or removed') |
UserDeleted | User deleted |
SuccessfulLogin | Successful login |
FailedLogin | Failed login |
TeamMemberAdded | Team member added |
TeamMemberDeleted | Team member deleted |
UserRolesUpdated | User roles updated (update includes 'roles added', 'roles removed' or 'roles added and removed') |
WindowsDomainDeleted | Windows domain deleted |
WindowsDomainUpdated | Windows domain updated |
WindowsDomainCreated | Windows domain created |
LdapServerDeleted | Ldap Server deleted |
LdapServerUpdated | Ldap Server updated |
LdapServerUpdated | Ldap Server created |
SamlServiceProviderUpdated | Saml Service Provider updated |
SamlIdentityProviderCreated | Saml Identity Provider created |
SamlIdentityProviderUpdated | Saml Identity Provider updated |
SamlIdentityProviderDeleted | Saml Identity Provider deleted |
RoleCreated | Role created (creation includes 'with permissions' or 'without permissions') |
RoleUpdated | Role updated (update includes 'no permissions added or removed', 'permissions removed' or 'permissions added') |
RoleDeleted | Role deleted |
The following information for each user action is listed in the AuditTrail database table:
Field | Description |
---|---|
Id | The event Id |
UserId | The user Id of the one who performed the action. NOTE: In case the UserId is NULL, it means that the action was performed automatically by the system. |
UserName | The user name of the one who performed the action. NOTE: In case the UserId is NULL, the UserName is System, except in case of FailedLogin (UserName doesn’t exist), whereas the UserName is the one provided by the user. |
Type | The type of user action that was performed (see the 'User Actions Type' table, above). |
Details | Details will differ, per user action type. Example 1: For a FailedLogin action, the failed user will be contained in the 'UserName' and the Authentication Provider type will be contained in the 'Details'. Example 2: For a TeamMemberAdded action, the user name & team name are contained in the 'Details'. |
Timestamp | Time/date of the user action. |
OriginIpAddress | The user’s IP address, which is logged for every action. NOTE: This can be especially useful for a FailedLogin – in order to understand how it occurred and where it came from. |