Home | SCM Onboarding | Okta SSO Authentication

SCM Administrator SSO with Okta

Configure SAML 2.0 federation so your administrators log in to Strata Cloud Manager through Okta

← SCM Onboarding Guide CIE Implementation Guide

About This Guide

This guide covers federating Strata Cloud Manager (SCM) administrator login to Okta using SAML 2.0. Once configured, administrators authenticate through your Okta tenant instead of a Palo Alto Networks account, allowing you to enforce MFA, apply Okta access policies, and centralize identity management for PAN products alongside the rest of your enterprise tooling.

This Is Not Cloud Identity Engine

Cloud Identity Engine (CIE) authenticates end users through firewalls and Prisma Access. This guide covers administrator login to the SCM portal itself. These are separate products with separate configurations. If you need Okta for firewall user authentication, see the CIE Implementation Guide.

SP-Initiated Flow Only

SCM does not support IdP-initiated SAML login. Administrators must navigate to apps.paloaltonetworks.com and be redirected to Okta from there. The Okta app tile cannot be used to launch a session directly.

Prerequisites

  • An active SCM or Common Services subscription (Essentials or Pro).
  • Your account holds the IAM Administrator or Superuser role in Common Services. This is typically the account that activated your subscription.
  • Admin access to your Okta tenant with permission to create SAML applications.
  • The ability to add a DNS TXT record to your public domain (for domain ownership verification).
  • At least one non-federated Superuser account kept active throughout this process as a fallback. If SSO becomes misconfigured or unavailable, this account is your recovery path.

Step 1: Verify Permissions

▶ Confirm your IAM role in Common Services
  1. Log in to apps.paloaltonetworks.com.
  2. Navigate to Common Services > Identity & Access > Access Management > Roles.
  3. Confirm your account holds IAM Administrator or Superuser.

If your account does not hold one of these roles, have a Superuser assign you the IAM Administrator role before continuing. Without it, the Identity Federations configuration is inaccessible.

Step 2: Add an Identity Federation and Verify Your Domain

PAN requires proof of domain ownership before federating any email domain. You add a DNS TXT record to your public DNS provider to verify control of the domain.

▶ Add federation and complete DNS verification
  1. Navigate to Common Services > Identity & Access > Access Management > Identity Federations.
  2. Click Add Identity Federation.
  3. Enter the email domain to federate (for example, company.com). Only letters, numbers, hyphens, and dots are allowed; maximum 50 characters.
  4. PAN generates a DNS TXT record. Copy the full record value.
  5. In your DNS provider, create a new TXT record for the domain using the copied value. If your current TTL is high, reduce it temporarily to speed propagation.
  6. Return to Identity Federations and click Verify Now.
Note

DNS propagation can take minutes to hours. If Verify Now fails, wait and retry. Once verification is confirmed, restore your DNS TTL to its original value. The TXT record can be removed after verification.

Step 3: Download the PAN Service Provider Metadata

PAN generates tenant-specific SAML Service Provider (SP) metadata containing the values Okta needs: the Entity ID, Assertion Consumer Service (ACS) URL, and SP certificate.

▶ Download the SP metadata XML file
  1. In Identity Federations, locate your verified domain.
  2. Click Download SP Metadata.
  3. Save the XML file. You will upload it to Okta in Step 4.
Note

The SP metadata values are tenant-specific and not published by PAN. Keep this file within your organization.

Step 4: Create a Custom SAML 2.0 App in Okta

There is no pre-built Okta gallery app for SCM administrator SSO. Create a custom SAML 2.0 application and configure it with the PAN SP metadata from Step 3.

▶ Create the Okta SAML app and configure attributes
  1. In the Okta Admin Console, navigate to Applications > Applications > Create App Integration.
  2. Select SAML 2.0 as the sign-on method and click Next.
  3. Enter an app name (for example, Palo Alto Networks SCM) and click Next.
  4. In the SAML Settings section, enter the values from your SP metadata XML file:
    • Single Sign-On URL: the ACS URL from the SP metadata
    • Audience URI (SP Entity ID): the Entity ID from the SP metadata
  5. Set Name ID format to EmailAddress.
  6. Under Attribute Statements, add these three required attributes exactly as shown:
    NameValue
    firstNameuser.firstName
    lastNameuser.lastName
    emailuser.email
  7. Under Group Attribute Statements, add a group attribute for role mapping:
    NameFilter
    groupsMatches regex .* (or a specific prefix to scope which groups are sent)
  8. In the App Visibility settings, uncheck any option that displays the app icon to users in the Okta portal. PAN does not support IdP-initiated login, and clicking the tile will not work.
  9. Click Finish, then assign the app to the relevant users or groups.
Missing Attributes Cause Blank Display Names

If firstName, lastName, or email are absent from the SAML assertion, users authenticate successfully but appear with blank names in the SCM interface. Verify all three attribute statements are configured exactly as shown.

Step 5: Get the Okta IdP Metadata

▶ Retrieve the Okta IdP metadata file or URL

After saving the Okta app, retrieve the Identity Provider metadata to upload to PAN. Two options are available:

  • Metadata file: In the Okta app, go to the Sign On tab and click Identity Provider metadata to download the XML file.
  • Metadata URL: The URL follows the pattern https://<your-domain>.okta.com/app/<appId>/sso/saml/metadata. Copy it from the Sign On tab.

Keep the file or URL ready for the next step. The metadata URL approach is simpler because it stays current if Okta rotates its certificate.

Step 6: Configure Okta as a SAML Provider in PAN and Enable the Login URL

▶ Upload Okta metadata and activate the Login URL
  1. Return to Common Services > Identity & Access > Access Management > Identity Federations.
  2. Locate your verified domain and click Configure Identity Provider.
  3. Choose one method to provide the Okta IdP metadata:
    • Upload metadata file: Upload the XML file from Step 5. All fields populate automatically. Click Finish.
    • Enter metadata URL: Paste the Okta metadata URL. Fields populate automatically. Click Finish.
    • Manual entry: Upload the Okta signing certificate (.crt format only), enter the IdP Entity ID/Issuer, and enter the IdP SSO URL. Click Next, then Finish.
  4. After saving, the Configure Identity Provider button is replaced by a Login URL. This URL is disabled by default.
  5. Click Actions > Enable to activate the Login URL.
Enable the Login URL

The Login URL is disabled after initial setup. Federation will not work until you explicitly enable it via Actions > Enable. This is the most common reason SSO appears fully configured but fails at login.

Certificate Format for Manual Entry

If using the manual entry method, the Okta certificate must be in .crt format. PEM and CER formats are not accepted. Use the metadata file or URL methods to avoid this restriction.

Step 7: Map Tenants for Authorization

Authentication and authorization are separate in PAN's identity federation. After establishing the SAML trust, you must explicitly map the federation to the tenants (TSGs) that federated users can access. Without this step, users authenticate successfully but have no access to any tenant.

▶ Map federation to SCM tenants
  1. In Identity Federations, locate your federation and click Edit Tenant Mapping for Authorization.
  2. Select which Tenant Service Groups (TSGs) the federation is authorized to access.
  3. Click Save.

Child tenants automatically inherit mappings from parent tenants. The Federated Role Mapping UI in Step 8 only shows tenants that have been mapped here.

Step 8: Configure Federated Role Mapping

Map Okta groups to SCM roles so users receive the correct permissions on login. PAN evaluates three SAML attributes and assigns roles on the first match: memberOf, strataCloudManagerRoles, and groups. The groups attribute configured in Step 4 satisfies this requirement.

▶ Map Okta groups to SCM roles
  1. Navigate to System Settings > Identity Federation > Federated Role Mapping.
  2. Select the target tenant from the dropdown. Only tenants mapped in Step 7 appear here.
  3. Click Add Role Mapping.
  4. Enter the Attribute Value: the Okta group name exactly as it appears in the SAML assertion (for example, SCM-Network-Admins).
  5. Select the Role to assign.
  6. Define the Scope within the tenant hierarchy.
  7. Click Save. Repeat for each group and role combination needed.
Available SCM Roles

Common roles include: Superuser, IAM Administrator, Security Administrator, Network Administrator, and Multitenant Administrator. Assign the minimum role required for each group.

Step 9: Test and Verify SSO Login

▶ Run an end-to-end SSO test
  1. Open a private or incognito browser window to avoid cached session state.
  2. Navigate to apps.paloaltonetworks.com.
  3. Enter a federated user's email address at the login screen.
  4. Confirm the browser redirects to your Okta login page.
  5. Authenticate with Okta credentials (and MFA if enforced by your Okta policy).
  6. After Okta authentication, confirm the user lands in SCM with the expected role and tenant access.
Success Indicators
  • User lands in SCM after Okta authentication without being prompted for a PAN password
  • Display name shows first and last name (not blank)
  • Tenant access and role match the mapping configured in Step 8
Keep a Fallback Admin Account

Before rolling out SSO to all administrators, confirm that at least one non-federated Superuser account remains active. Use this account to regain access if SSO breaks or is misconfigured.

Troubleshooting

▶ SSO configured but login still fails or redirects to PAN login

Most likely cause: The Login URL is disabled. This is the default state after configuring the SAML provider.

Fix: Go to Common Services > Identity & Access > Access Management > Identity Federations, locate your federation, click Actions > Enable.

▶ User authenticates but displays a blank name in SCM

Cause: The firstName, lastName, or email attribute statements are missing or incorrectly named in the Okta SAML app.

Fix: In the Okta app, go to Sign On > SAML Settings > Edit and verify all three attribute statements match these exact names and values:

NameValue
firstNameuser.firstName
lastNameuser.lastName
emailuser.email
▶ User authenticates but has no access to any tenant

Cause: Tenant mapping for authorization was not completed (Step 7). Authentication and authorization are separate in PAN's identity federation.

Fix: In Identity Federations, click Edit Tenant Mapping for Authorization for your federation and select the relevant tenants.

▶ DNS TXT verification fails

Cause: The TXT record has not propagated yet, or was entered incorrectly.

Fix: Verify the record is correct with dig TXT yourdomain.com or a public DNS lookup tool. If the record is present but verification still fails, wait for propagation and retry. DNS TTL delays are the most common cause.

▶ Certificate upload fails during manual SAML configuration

Cause: PAN's manual entry method only accepts .crt format certificates. PEM, CER, and other formats are rejected.

Fix: Convert the Okta certificate to .crt format, or switch to the metadata file or URL methods (Steps 5 and 6), which do not have this restriction.

▶ Federated Role Mapping dropdown shows no tenants

Cause: No tenants have been mapped for authorization in Step 7. The Role Mapping UI only shows tenants that are explicitly mapped.

Fix: Complete Step 7 first (Edit Tenant Mapping for Authorization in Identity Federations), then return to Federated Role Mapping.