> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-authentication/authenticate-users-using-sso.md). # Authenticate users using SSO Cortex XSIAM 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 XSIAM, and which values to add to your IdP fields. {% hint style="info" %} ### Note * 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 XSIAM 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 XSIAM. * 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 XSIAM. * 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 XSIAM. {% endhint %}
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. For detailed implementation steps and advice on structuring these permissions, see. **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 XSIAM 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 XSIAM. 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 XSIAM, go to Settings → Configurations → Access Management → **Authentication Settings**. 2. In the **Login Options** tab, toggle **SSO Disabled** to on. You can see the SSO settings, so you can configure them according to your organization’s IdP. 3. 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.

Note

4. 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) 5. **Save** your changes. Whenever an SSO user logs in to Cortex XSIAM, 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.

Important

PROGRAMMATIC CONTRAINT:

There is no public API endpoint available to provision or de-provision users programmatically within Cortex XSIAM. 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 XSIAM 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\://\.crtx.paloaltonetworks.com/idp/saml. For example,

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\://\.paloaltonetworks.com. For example .

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 XSIAM 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@\). 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 XSIAM 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 XSIAM. 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 XSIAM. | | 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 XSIAM, 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 XSIAM, 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://.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 XSIAM 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 XSIAM 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 XSIAM settings. * SAML attributes from the IdP are not properly mapped in Cortex XSIAM. The attributes are case sensitive and must exactly match in your IdP and in the Cortex XSIAM **IdP Attributes Mapping**. * Group memberships from the IdP have not been properly mapped to Cortex XSIAM user groups. Verify the values your identity provider is sending, to properly map the groups in Cortex XSIAM. * 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.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-authentication/authenticate-users-using-sso.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.