Skip to main content

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.

6590890383.png

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.

  1. AST roles – There are two types of AST roles, Composite roles & Action roles.

    1. 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.

    2. Action role - A single-action role. This role type defines permissions for actions in the system.

  2. CB roles - Codebashing roles.

  3. 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.

6590890429.png
6590890432.png

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.

6590890508.png

On the right-hand corner, you have an option, Add a provider select SAML 2.0 or OpenID Connect 1.0.

6590890505.png

Please see the following documentation to learn more about these configurations.

Configuring SAML Integration

Configuring OpenID Connect Integration

Creating OAuth Clients

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

  • On: The provided email is not verified even if verification is enabled for the realm.

  • Off: The provided email is verified.

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

  • On: Users cannot log in through this provider and they can only link to this provider. This is useful if you don't want to allow login from the provider but want to integrate with the provider.

  • Off: Users can log in through this provider.

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.

  • 1 is the highest value.

  • This is useful when using several external providers.

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:

  • legacy to keep the behavior before this option was introduced

  • import to only import the user once during the first login of the user with this identity provider

  • force to always update the user during every login with this identity provider

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:

  • Single Logout Service URL needs to be filled with the log out URL address.

  • Backchannel Logout option needs to be enabled.

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

  • Default is set to Subject NameID

  • Optional Values: Subject NameID, Attribute [Name], Attribute [Friendly Name]

  • If Attribute [Name] / Attribute [Friendly Name] is selected, an additional Principal Attribute field will be added.

HTTP-POST Binding Response

Indicates how the external provider returns the information to the client.

Off

  • On: Use POST for Binding Response.

  • Off: HTTP-Redirect Binding will be used (GET)

HTTP-POST Binding for AuthnRequest

Indicates which SAML binding should be used when the client requests authentication from the external provider.

Off

  • On: Use POST for Binding Response.

  • Off: Redirect Binding will be used (GET)

HTTP-POST Binding Logout

Indicates which SAML binding should be used for logging out from the external provider.

Off

  • On: Use POST for Binding Response.

  • Off: HTTP-Redirect Binding will be used (GET).

  • If value is On, the system will use the Single Logout Service URL value for logging out.

Want AuthnRequests Signed

Indicates whether the identity provider expects a signed AuthnRequests.

Off

If this value is On, 2 additional fields will be added:

  • Signature Algorithm: Which signature algorithm to use for signing documents. Optional values are: RSA_SHA256 (Default), RSA_SHA1, RSA_SHA512, DSA_SHA1

  • SAML Signature Key Name: Signed SAML documents contain identification of signing key in the KeyName element. Optional values are: Empty value (Default), None, KEY_ID, CERT_SUBJET

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 SAML Integration

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

  • On: The provided email is not verified even if verification is enabled for the realm.

  • Off: The provided email is verified.

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

  • On: Users cannot log in through this provider, they can only link to this provider. This is useful if you don't want to allow login from the provider but want to integrate with the provider.

  • Off: Users can log in through this provider.

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.

  • 1 is the highest value.

  • This is useful when using several external providers.

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.

  • Defaults to openid

  • Can also be a space-separated list of scopes

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.

Configuring OpenID Connect Integration