- Checkmarx Documentation
- Checkmarx One
- Checkmarx One Learning Tracks
- Checkmarx One Learning Tracks - Operations
- Deploying Checkmarx One with your organization
- Configuring Authentication and Authorization
Configuring Authentication and Authorization
Configuring built-in Authentication and Authorization
In Checkmarx, you can use the built-in Identity and Access Management console to create and manage users.
This feature provides you with built-in Authentication for users, allowing them to log into the Checkmarx One platform using the browser.
When the user inserts their username and password details in the login fields, the backend code hits the database to look up and see if that user exists.
If the user exists, it will then confirm the password as well. If the username and password match, the login is successful.
Now let´s take a look at Authorization.
When Admins manage users, they also need to define the role of each and what access they should have.
In Checkmarx, Authorization is managed using Groups and Roles that restrict or allow end-users permissions and access to perform specific actions.
The Groups section allows you to manage a set of attributes and role mappings for a set of users.
Users can be members of zero or more groups, and they can inherit the attributes and role mappings assigned to each group.
It is possible to perform the following tasks in the Groups section:
Manually create groups in the platform.
Manage the groups in the platform.
Represent the reflection of all the organization groups via LDAP, SAML, or OpenID Connect.
For a detailed procedure on how to configure a provider LDAP, SAML, or OpenID Connect see Managing Identity Providers pages.
Groups are hierarchical and can have many subgroups, but a group can only have one parent. Subgroups inherit the attributes and role mappings from the parent. This rule applies to the users as well. So, if you have a parent group and a child group and a user that only belongs to the child group, the user inherits the attributes and role mappings of both the parent and child.
There are three types of roles. AST roles, CB roles, and IAM roles.
AST roles – There are two types of AST roles, Composite roles & Action roles.
Composite roles - This is a role with one or more additional roles associated with it. When a composite role is mapped to the user, the user also gains the roles associated with that composite. This inheritance is recursive, so any composite of composites also gets inherited.
Action role - A single-action role. This role type defines permissions for actions in the system.
CB roles - Codebashing roles.
IAM (Identity and Access Management) roles - System roles.
A Composite role is an aggregation of single actions combined into one role type.
For example, the ast-viewer role allows users to view all project-related data, such as viewing projects, scans, and scan results.
The Identity and Access Management console comes with out-of-the-box roles, called Composite roles. You can modify these roles according to your specific needs, and new customized composite roles can be added to the existing roles list if needed.
An Action role is a single action role. This role type defines permissions for actions in the system.
The IAM roles are related to the actions available for the Identity and Access Management console. The IAM roles types are: iam-admin used to manage users, client credentials, identity providers, and user federation. The manage-users role for managing the users in the system.
For a more detailed list of the predefined roles provided for Checkmarx One, along with their respective permissions, see Managing Roles.
Configuring LDAP
LDAP is an open communication protocol in the application layer that allows access and management of a Directory service over IP networks.
LDAP is used to create a stable connection between several services (SSO).
Integrating Checkmarx One with an LDAP server will reflect your user and group trees in the platform.
For more details and instructions on how to configure LDAP with Checkmarx One, see Configuring LDAP Integration.
Configuring Identity Providers
The Identity Providers section enables organizations to add an external identity management provider.
When you configure an existing identity provider and Checkmarx One, the users are authenticated against the identity provider and not against Checkmarx One.
We support connecting to multiple identity providers, with the ability to configure their priority.
You will find the Identity Providers section in the Identity and Access Management Console of the navigation panel.
On the right-hand corner, you have an option, Add a provider select SAML 2.0 or OpenID Connect 1.0.
Please see the following documentation to learn more about these configurations.
Configuring OpenID Connect Integration
Configuring SAML 2.0 providers
The SAML configuration window has two sections, App Settings, and SAML Settings.
App Settings
This configuration section refers to the Identity and Access Management (Broker) side.
In this section, we will provide a brief description of each field. We will also identify which settings are mandatory.
Field Name | Description | Default | Configuration Details |
---|---|---|---|
Redirect URI | Client redirect URI. | The redirect URI to use when configuring the identity provider. URI must be added to the identity provider settings. | |
Alias | The alias uniquely identifies an identity provider and is used to build the redirect URI. | This field is mandatory. | |
Display Name | The name is presented in the identity provider’s table. | This is a friendly name for identity providers. | |
Enabled | Enable/disable identity provider. | On | This option must be enabled. |
Store Tokens | Enable/disable if tokens must be stored after authenticating users. | Off | Determine if to save the token in CxOne DB in an encoded format, after the users' authentication |
Stored Tokens Readable | Enable/disable if new users can read any stored tokens. This assigns the broker.read-token role. | Off | Determine if to save the token in CxOne DB in a Decoded format, after the users' authentication |
Trust Email | Determines whether the email is verified. | Off |
|
Account Linking Only | Allows users to login in with the provider and integrate with the provider or prevents login from the provider while still integrating with a provider. | Off |
|
Hide on Login Page | Determine if to hide the external provider icon in the CxOne log in page | Off | If hidden, login with the provider is possible only if requested explicitly, for example, using the ‘kc_idp_hin’ parameter. |
GUI order | Number defining the order of the provider in GUI, for example on the Login page. |
| |
First Login Flow | Alias of authentication flow, which is triggered after first login with this identity provider. | The term, first login, means that no Keycloak account is currently linked to the authenticated identity provider account. | |
Post Login Flow | Alias of authentication flow which is triggered after each login with this identity provider. | Useful if you want additional verification of each user authenticated with this identity provider, for example OTP. Leave this empty if you need no additional authenticators to be triggered after login with this identity provider. Also not that authenticator implementations must assume that user is already set in ClientSessions as identity provider already set it. | |
Sync Mode | Default sync mode for all mappers. The sync mode determines when user data will be synced using the mappers. | Possible values are:
|
SAML Settings
This configuration section refers to the external provider side (not the client).
Below are all the configuration options that exist in this section.
Field Name | Description | Default | Configuration Details |
---|---|---|---|
Single Sign-On Service URL | The URL that is used for SAML SSO log in authentication requests. | This field is mandatory. This field will fill automatically once you import the metadata URL from the identity provider. | |
Single Logout Service URL | The URL that is used for external provider log out authentication requests. | For a user to log out from the external provider (when they log out from CxAST), you need to perform the following:
| |
Backchannel Logout | Does the external IDP support backchannel logout? | Off | In case this option is enabled, it supports logging out from the identity provider when logging out from CxOne application. |
NameID Policy Format | Specifies the URI reference corresponding to a name identifier format, in other words, how to send the details in the SAML XML assertion format. | Persistent | Optional Values: Persistent, Email, Kerberos, X.509 Subject Name, Windows Domain Qualified Name, Unspecified Defaults to urn:oasis:names:tc:SAML:2.0:nameid-format:persistent |
Principal Type | Way to identify and track external users from the assertion. | Subject NameID |
|
HTTP-POST Binding Response | Indicates how the external provider returns the information to the client. | Off |
|
HTTP-POST Binding for AuthnRequest | Indicates which SAML binding should be used when the client requests authentication from the external provider. | Off |
|
HTTP-POST Binding Logout | Indicates which SAML binding should be used for logging out from the external provider. | Off |
|
Want AuthnRequests Signed | Indicates whether the identity provider expects a signed AuthnRequests. | Off | If this value is On, 2 additional fields will be added:
|
Want Assertions Signed | Indicates whether this service provider expects a signed Assertion. | Off | |
Want Assertions Encrypted | Indicates whether this service provider expects an encrypted Assertion. | Off | |
Force Authentication | Indicates whether the identity provider must authenticate the user directly rather than relying on a previous security context. | Off | |
Validate Signature | Enable/disable signature validation of SAML responses. | Off | If this value is On, an additional Validating X509 Certificates field will be added. This is an indication of the certificate in PEM format that must be used for checking signatures. Multiple certificates can be entered, separated by a comma. |
Allowed clock skew | Clock skew in seconds that is tolerated when validating identity provider tokens. | zero | Default value is zero. |
Import from URL | Import metadata from a remote IDP SAML entity descriptor. | Import metadata URL from the identity provider settings. | |
Import from file | Import metadata from a file | If the import is being performed using a file, there is a need to click the Select file button, and to select the requested file. |
Below we have two videos that guide you through the configuration of the SAML using Azure Active Directory and OKTA.
Please see the articles below for more details and instructions.
Configuring OpenID Connect 1.0 providers
The OpenID Connect configuration window has two sections, App Settings, and OpenID Connect Settings.
App Settings
This configuration section refers to the Identity and Access Management (Broker) side.
In this section, we will provide a brief description of each field. We will also identify which settings are mandatory.
Field Name | Description | Default | Configuration Details |
---|---|---|---|
Redirect URI | Client redirect URI. | The redirect URI to use when configuring the identity provider. URI must be added to the identity provider settings. | |
Alias | The alias uniquely identifies an identity provider and is used to build the redirect URI. | This field is mandatory. | |
Display Name | The name is presented in the identity provider’s table. | This is a friendly name for identity providers. | |
Enabled | Enable/disable identity provider. | On | This option must be enabled. |
Stored Tokens Readable | Enable/disable if new users can read any stored tokens. This assigns the broker.read-token role. | Off | Determine if to save the token in CxAST DB in a Decoded format, after the users´ authentication |
Trust Email | Determines whether the email is verified. | Off |
|
Account Linking Only | Allows you to choose if the users can log in and integrate with the provider or if they can only log in with the provider. | Off |
|
Hide on Login Page | Determines if the external provider icon is hidden in the CxAST log in page. | Off | If hidden, login with the provider is possible only if requested explicitly, for example, using the ‘kc_idp_hin’ parameter. |
GUI order | Number defining the order of the provider in GUI, for example on the Login page. |
| |
First Login Flow | Alias of authentication flow, which is triggered after first login with this identity provider. | The term, first login, means that no Keycloak account is currently linked to the authenticated identity provider account. | |
Post Login Flow | Alias of authentication flow which is triggered after each login with this identity provider. | Useful if you want additional verification of each user authenticated with this identity provider, for example OTP. Leave this empty if you need no additional authenticators to be triggered after login with this identity provider. Also not that authenticator implementations must assume that user is already set in ClientSessions as identity provider already set it. |
OpenID Connect Settings
This configuration section refers to the external provider side (not the client).
In this section, we will provide you with a description of each field. We will also identify the mandatory settings.
Field Name | Description | Default | Configuration Details |
---|---|---|---|
Authorization URL | The Authorization URL. | This field is mandatory. Use your identity provider details to retrieve URL. | |
Pass login_hint | Pass login_hint to identity provider. | ||
Pass current locale | Pass the current locale to the identity provider as a ui_locales parameter. | ||
Token URL | The Token URL. | This field is mandatory. Use your identity provider details to retrieve URL. | |
Logout URL | End session endpoint to use to logout user from external IDP. | ||
Backchannel Logout | Does the external IDP support backchannel logout? | Off | In case this option is enabled, it supports logging out from the identity provider when logging out from CxOne application. |
Disable User Info | Disable usage of User Info service to obtain additional user information. | Default is to use this ODIC service. | |
User Info URL | The User Info URL. | This is optional. | |
Client Authentication | The client authentication method. | This field is mandatory. https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication In case JWT is signed with private key, the realm private key is used. | |
Client ID | The client identifier registered within the identity provider. | This field is mandatory. These details are found in the identity provider settings. | |
Client Secret | The client secret registered within the identity provider. | This field is mandatory. These details are found in the identity provider settings. This field is able to obtain its value from vault, use ${ vault.ID } format. | |
Issuer | The issuer identifier for the issuer of the response. | If not provided, no validation will be performed. | |
Default Scopes | The scopes to be sent when asking for authorization. |
| |
Prompt | Determines whether the Authorization Server prompts the end-user to authenticate again and give consent. | ||
Accepts prompt=none forward from client | This is used together with the identity provider authenticator or when kc_idp_hint points to this identity provider. | If a client sends a request with prompt=none and the user not authenticated, the error would not be returned to the client. Instead, the request with prompt=none would be returned to this identity provider. | |
Validate Signatures | Enable/disable signature validation of external IDP signatures. | Off | If this value is On, an additional Validating X509 Certificates field will be added. This is an indication of the certificate in PEM format that must be used for checking signatures. Multiple certificates can be entered, separated by a comma. |
Use JWKS URL | This allows flexibility because new keys will always re-downloaded again when an identity provider generates new keypair. | When ON, identity providers public keys will be downloaded from given JWKS URL. If the switch is OFF, the public key (or certificate) from the Keycloak DB is used, so when the identity provider keypair changes, you need to import the new key to the Keycloak DB as well. | |
JWKS URL | URL where identity provider keys in JWK format are stored. | See JWK specifications for more details. If you use an external Keycloak identity provider, you can use a URL like, http://broker-keycloak:8180/auth/realms/test/protocol/openid-connect/certs assuming your brokered Keycloak is running on http://broker-keycloak:8180 and its realm is 'test' . | |
Allowed clock skew | Clock skew in seconds that is tolerated when validating identity provider tokens. | zero | Default value is zero. |
Forwarded Query Parameters | Non OpenID Connect/OAuth standard query parameters to be forwarded to external IDP from the initial application request to Authorization endpoint. | Multiple parameters can be entered, separated by a comma (,). |
The video below shows how to configure OpenID Connect 1.0 using OKTA.
Please see this article for more details and instructions to configure OpenID Connect.