Authenticate users using SSO

Configure SAML 2.0 SSO for Cortex AgentiX with identity provider mapping, user groups, roles, and tenant access.

Cortex AgentiX enables you to authenticate system users securely across enterprise-wide applications and websites with one set of credentials using single sign-on (SSO) with SAML 2.0. System users can authenticate using your organization's Identity Provider (IdP), such as Okta or PingOne. You can integrate with any IdP that is supported by SAML 2.0.

Use SAML SSO when you want your platform users to be authenticated according to your organization's precise security standards as implemented within your enterprise IdP. This is critical for enforcing corporate Multi-Factor Authentication (MFA) mandates, identity verification policies, handling automatic de-provisioning (for example, when a user leaves the company), or specific conditional network access rules before granting portal access.

Configuring SSO with SAML 2.0 is dependent on your organization’s IdP. Some of the parameter values need to be supplied from your organization’s IdP and some need to be added to your organization’s IdP. You must have sufficient knowledge about IdPs, how to access your organization’s IdP, which values to add to Cortex AgentiX, and which values to add to your IdP fields.

• To set up SSO authentication in the tenant, you must be assigned an Instance Administrator or Account Admin role.

• SAML 2.0 users must log in to Cortex AgentiX using the FQDN (full URL) of the tenant. To allow login directly from the IdP to , you must set the relay state on the IdP to the FQDN of the tenant.

• If you have multiple tenants, you must set up the SSO configuration separately for each tenant, both in the IdP and in Cortex AgentiX.

• If you are using AWS SSO, the Application ACS URL refers to the Single Sign-On URL and the Application SAML Audience refers to the Audience URL (SP Entity ID). Both values can be copied from the Authentication Settings in Cortex AgentiX.

• Unlike users who authenticate through the Customer Support Portal (CSP), users who log in via SSO do not require the Cortex User role to be assigned in the CSP. Their access and permissions are governed by the SAML Group Mapping configured in Cortex AgentiX.

Identity provisioning and de-provisioning lifecycle

Just-In-Time (JIT) account creation

When an enterprise user authenticates through your configured Identity Provider (IdP) for the very first time, an explicit user account entry is dynamically generated inside the platform via Just-In-Time (JIT) provisioning. Once provisioned, this newly formed user identity appears within the primary Users Table console.

Following initial JIT creation, administrators can open the account entry to assign targeted Access Management controls, defining precise Roles and granular data Scopes. You can choose to select an optional global Default Role parameter within the general SSO configuration menu to automatically apply baseline permissions to newly provisioned users.

To maintain a secure posture, it is critical that this Default Role is configured with the least-privileged permissions possible (such as read-only or a basic viewer role) to ensure users without explicit role or group assignments inherit minimal access by default.

Security minimization best practice

If a Default Role is utilized for JIT automation, it is strongly recommended to restrict this role to the most minimal, low-privilege read-only permissions possible. This ensures that if a platform administrator forgets to manually apply an explicit target role or scope assignment to a newly synced user, that account remains structurally isolated from sensitive security controls or data views.

Once account objects successfully register via JIT login, administrators can manually pair those known identities directly with local Custom Cortex User Groups within the console.

Deprovisioning and account disabling actions

• Identity Provider (IdP) account suspensions: If a user account is deleted, suspended, or disabled directly within your organization's external Identity Provider (IdP), that target user is blocked from executing any further single sign-on validation attempts into Cortex AgentiX if you set SSO as the authentication method, taking effect upon their next login sequence. For continuity tracking purposes, the historical record for that user will continue to populate inside the internal console Users table until an inactivity threshold triggers a backend purge. For more information, see the [Inactivity removal cycles] policy explained directly below.

• Inactivity removal cycles: For accounts bound to both single sign-on (SSO) pipelines and native Customer Support Portal (CSP) infrastructure, identity profiles and group mappings are automatically purged and removed from the platform console following a specified period of prolonged system inactivity. This inactivity threshold is explicitly configured by navigating to Settings → Configurations → General → Security Settings and selecting Enabled from the Deactivate Inactive User drop-down menu. Selecting this option exposes the Deactivation period field, which is set to 30 days by default, allowing administrators to specify the exact number of inactive days required to trigger user deactivation.

• Cloud Identity Engine (CIE) separation boundary: Disabling, removing, or changing user records directly inside the Cloud Identity Engine interface does not disable, modify, or block corresponding user accounts inside Cortex AgentiX. User lifecycle connectivity is governed purely by active IdP authentication responses or CSP invitation status.

If you are configuring Okta or Microsoft Entra ID, follow the procedure in Okta or Microsoft Entra ID. You can also adapt these instructions for use with any similar SAML 2.0 IdP.

1. In Cortex AgentiX, navigate to Settings → Configurations → Access Management → Authentication Settings.

2. If you want to add another SSO connection to enable managing user groups with different roles and different IdPs, click Add SSO Connection.

   Different SSO parameters for an SSO are displayed to configure according to your organization’s additional IdP.

   • The first SSO cannot be deleted; it can only be deactivated by toggling SSO Enabled to off.

   • The Domain parameter is predefined for the first SSO.

     If you add additional SSO providers, you must provide the email Domain in the SSO Integration settings for all providers except the first. Cortex AgentiX uses this domain to determine to which identity provider to send the user for authentication.

   • When mapping IdP user groups to Cortex AgentiX user groups, you must include the group attribute for each IdP you want to use. For example, if you are using Microsoft Entra ID and Okta, your Cortex AgentiX user group SAML Group Mapping field must include the IdP groups for each provider. Each group name is separated by a comma.

3. Set the following parameters using your organization’s IdP, where the field parameters are explained in the tables below.

   • General parameters

   • IdP Attribute Mapping

   • Advanced Settings (optional)

4. Save your changes.

   Whenever an SSO user logs in to Cortex AgentiX, the following login options are available.

   • Sign-in with SSO

     If you have enabled more than one SSO provider, an optional email field appears. If the user does not enter an email address or if the email address does not match an existing domain, the user is automatically directed to the default IdP provider (the first in the list of SSO providers in the Authentication Settings). If the user enters an email address and it matches a domain listed in the Domain field in the SSO Integration settings for one of your IdPs, Sign-In with SSO sends the user to the IdP associated with that email domain.

   Programmatic constraint:

   There is no public API endpoint available to provision or de-provision users programmatically within Cortex AgentiX. All target accounts must be initialized or explicitly managed using the native interactive Single Sign-On (SSO) or Customer Support Portal (CSP) interface workflows defined in this guide. To review the list of supported programmatic actions and ingestion endpoints, see the Cortex AgentiX API Reference guide.

General parameters

Parameter	Description
IdP SSO or Metadata URL	Select the option that meets your organization's requirements. Indicates your SSO URL, which is a fixed, read-only value based on your tenant's URL using the format https://<name of tenant>.crtx.paloaltonetworks.com/idp/saml. For example, https://tenant1.crtx.paloaltonetworks.com/idp/saml You need this value when configuring your IdP.
IdP SSO URL	Specify your organization’s SSO URL, which is copied from your organization’s IdP.
Metadata URL
Audience URI (SP Entity ID)	Indicates your Service Provider Entity ID, also known as the ACS URL. It is a fixed, read-only value using the format, https://<name of tenant>.paloaltonetworks.com. For example https://tenant1.crtx.paloaltonetworks.com. You need this value when configuring your organization’s IdP.
Default Role	(Optional) Select the default role that you want any user to automatically receive when they are granted access to Cortex AgentiX through SSO. This is an inherited role and is not the same as a direct role assigned to the user.
IdP Issuer ID	Specify your organization’s IdP Issuer ID, which is copied from your organization’s IdP.
X.509 Certificate	Specify your X.509 digital certificate, which is copied from your organization’s IdP.
Domain	Relevant only for multiple SSOs. For one SSO, this is a fixed, read-only value. Associate this IdP with a specific email domain (user@<domain>). When logging in, users are redirected to the IdP associated with their email domain or to the default IdP if no association exists.

IdP attribute mapping

These IdP attribute mappings are dependent on your organization’s IdP.

Parameter	Description
Email	Specify the email mapping according to your organization’s IdP.
Group Membership	Specify the group membership mapping according to your organization’s IdP. Note Cortex AgentiX requires the IdP to send the group membership as part of the SAML token. Some IdPs send values in a format that include a comma, which is not compatible with Cortex AgentiX. In that case, you must configure your IdP to send a single value without a comma for each group membership. For example, if your IdP sends the Group DN (a comma-separated list), by default, you must configure IdP to send the Group CN (Common Name) instead.
First Name	Specify the first name mapping according to your organization’s IdP.
Last Name	Specify the last name mapping according to your organization’s IdP.

Advanced settings

The following advanced settings are optional to configure and some are specific for a particular IdP.

Parameter	Description
Relay State	(Optional) Specify the URL for a specific page that you want users to be directed to after they’ve been authenticated by your organization’s IdP and log in to Cortex AgentiX.
IdP Single logout URL	(Optional) Specify your IdP single logout URL provided by your organization’s IdP to ensure that when a user initiates a logout from Cortex AgentiX, the identity provider logs the user out of all applications in the current identity provider login session.
SP Logout URL	(Optional) Indicates the Service Provider logout URL that you need to provide when configuring a single logout from your organization’s IdP to ensure that when a user initiates a logout from Cortex AgentiX, the identity provider logs the user out of all applications in the current identity provider login session. This field is read-only and uses the following format https://<name of tenant>.crtx.paloaltonetworks.com/idp/logout, such as https://tenant1.crtx.paloaltonetworks.com/idp/logout.
Service Provider Public Certificate	(Optional) Specify your organization’s IdP service provider public certificate.
Service Provider Private Key (Pem Format)	(Optional) Specify your organization’s IdP service provider private key in Pem Format.
Remove SAML RequestedAuthnContext	(Optional) Requires users to log in to Cortex AgentiX using additional authentication methods, such as biometric authentication. Selecting this removes the error generated when the authentication method used for previous authentication is different from the one currently being requested. See here for more details about the RequestedAuthnContext authentication mismatch error.
Force Authentication	(Optional) Requires users to reauthenticate to access the Cortex AgentiX tenant if requested by the idP, even if they already authenticated to access other applications.

Troubleshoot SSO issues

The following list describes the common errors and issues when using SAML 2.0 authentication.

• Errors in your IdP could mean the Service Provider Entity ID and/or Service Identifier are not properly configured in the IdP or in the Cortex AgentiX settings.

• SAML attributes from the IdP are not properly mapped in Cortex AgentiX. The attributes are case sensitive and must exactly match in your IdP and in the Cortex AgentiX IdP Attributes Mapping.

• Group memberships from the IdP have not been properly mapped to Cortex AgentiX user groups. Verify the values your identity provider is sending, to properly map the groups in Cortex AgentiX.

• The identity provider is not configured to sign both the SAML response and the assertion on the login token. Your IdP must be configured to sign both to ensure a secure login.

• If you require further troubleshooting, we recommend using your browser's built-in developer tools or additional browser plugins to capture the login request and SAML token.