Integrations

ServiceNow Ping Identity Integration Guide

advancedSAML 2.0 with XML Digital SignaturesPing Identity

The ServiceNow Ping Identity integration establishes PingFederate as a SAML 2.0 Identity Provider (IdP) for ServiceNow, enabling enterprise single sign-on and centralized identity management. This integration solves the challenge of managing user authentication across multiple enterprise applications by providing seamless SSO access to ServiceNow while maintaining security and compliance requirements through centralized identity governance. Organizations with existing Ping Identity infrastructure use this integration to leverage their investment in identity management while extending SSO capabilities to ServiceNow. The integration supports uni-directional authentication flows from PingFederate to ServiceNow, with optional bi-directional attribute synchronization for user provisioning and profile updates. The primary authentication pattern uses SAML 2.0 assertions triggered by user login attempts, with configuration managed through ServiceNow's Multi-Provider Single Sign-On plugin and System Security modules.

Prerequisites

  • ServiceNow Quebec or later with Multi-Provider Single Sign-On plugin activated
  • PingFederate 10.0 or later with administrative access
  • ServiceNow admin role or equivalent SAML configuration permissions
  • Access to ServiceNow instance metadata URL (https://instance.service-now.com/saml_metadata.do)
  • SSL certificate management capabilities in both systems
  • Understanding of SAML 2.0 protocol and XML metadata structures
  • Network connectivity between PingFederate and ServiceNow instance

Architecture Overview

The ServiceNow Ping Identity integration uses the native Multi-Provider Single Sign-On (SSO) plugin without requiring Integration Hub spokes or custom REST integrations. Authentication is established through SAML 2.0 federation metadata exchange, with PingFederate acting as the Identity Provider and ServiceNow as the Service Provider. The data flow is uni-directional during authentication, with SAML assertions containing user attributes flowing from PingFederate to ServiceNow upon successful authentication attempts. No MID Server is required since the integration uses direct HTTPS communication between PingFederate and ServiceNow for metadata exchange and assertion processing. The integration leverages ServiceNow's built-in SAML processing capabilities through the Multi-Provider SSO Configuration records and Identity Provider records, with minimal API rate limiting concerns since authentication requests are user-driven rather than batch-processed.

Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Implementation Steps

1

Configure ServiceNow as SAML Service Provider

Navigate to System Security > Single Sign-On > Multi-Provider SSO > Properties and ensure the Multi-Provider SSO plugin is active. Set the 'glide.authenticate.sso.redirect.idp' property to your desired Identity Provider name for automatic redirects. Configure the ServiceNow instance as a Service Provider by navigating to Multi-Provider SSO > Identity Providers and clicking 'New'. Enter a descriptive name like 'PingFederate Production' and set the Import IdP Metadata field to false initially since you'll configure attributes manually first.

2

Download ServiceNow metadata and configure PingFederate SP connection

Access your ServiceNow instance metadata by navigating to https://your-instance.service-now.com/saml_metadata.do and save the XML file. In PingFederate administrative console, navigate to Applications > Integration > SP Connections and create a new Service Provider connection. Upload the ServiceNow metadata file and configure the connection name as 'ServiceNow Production'. Verify that the Entity ID matches your ServiceNow instance URL and that the Assertion Consumer Service URLs are correctly imported from the metadata.

3

Configure attribute mapping in PingFederate

In the PingFederate SP connection configuration, navigate to the Attribute Contract tab and add required attributes including 'email', 'user_name', 'first_name', 'last_name', and any custom attributes needed for ServiceNow user provisioning. Configure attribute sources by mapping these contracts to your LDAP directory, database, or other attribute stores. Set up the attribute contract fulfillment by mapping source attributes to the contract attributes, ensuring that 'email' maps to the user's email address and 'user_name' maps to the ServiceNow user ID field. Verify that attribute values will be populated correctly by testing with a sample user account.

4

Export PingFederate metadata and import into ServiceNow

In PingFederate, navigate to Server Configuration > Administrative Functions > Metadata Export and download the Identity Provider metadata XML file. Return to ServiceNow and open your Identity Provider record created in step 1, then set Import IdP Metadata to true and upload the PingFederate metadata file. ServiceNow will automatically populate the IdP URL, Certificate, and other federation settings from the metadata. Verify that the Name ID Format is set to 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified' or your preferred format, and ensure the IdP Entity ID matches your PingFederate configuration.

5

Configure SAML attribute mapping in ServiceNow

Navigate to the Attribute Map related list on your Identity Provider record and create new SAML attribute mappings for each attribute sent by PingFederate. Create mappings for 'email' to 'Email', 'user_name' to 'User ID', 'first_name' to 'First name', and 'last_name' to 'Last name' fields. Ensure that the 'User ID' mapping is marked as the User Field since this will be used to match or create user accounts. For just-in-time provisioning, verify that the 'Create User' checkbox is enabled on the Identity Provider record to allow automatic user account creation for new users.

6

Configure advanced SSO settings and user provisioning

On the Identity Provider record, configure advanced settings including the Default Role for new users (typically 'snc_internal' or your organization's default role), Login URL for IdP-initiated SSO, and Logout URL for proper session termination. Set up attribute-based role assignment by creating User Criteria records that map SAML attributes to ServiceNow roles or groups. Enable 'Update User' if you want ServiceNow to update user profiles based on SAML attributes on each login. Configure the 'User Provisioning Script' if you need custom logic for user creation or updates beyond standard attribute mapping.

ServiceNow Script
// Custom user provisioning script example
(function(user_sys_id, saml_response) {
    var user = new GlideRecord('sys_user');
    if (user.get(user_sys_id)) {
        // Custom provisioning logic
        var department = saml_response.getAttribute('department');
        if (department) {
            user.department = department;
            user.update();
        }
        
        // Assign role based on SAML attribute
        var userRole = saml_response.getAttribute('role');
        if (userRole && userRole == 'admin') {
            var gr = new GlideRecord('sys_user_has_role');
            gr.initialize();
            gr.user = user_sys_id;
            gr.role = 'admin';
            gr.insert();
        }
    }
})(user_sys_id, saml_response);
7

Enable SSO and configure login redirection

Navigate to System Security > Single Sign-On > Multi-Provider SSO > Properties and set 'glide.authenticate.sso.redirect.idp' to the name of your PingFederate Identity Provider to enable automatic redirection to PingFederate for authentication. Configure the 'glide.authenticate.multisso.redirect.url' property if you need custom redirection logic or want to present users with IdP selection options. Test the configuration by logging out of ServiceNow and attempting to access the instance - you should be automatically redirected to PingFederate for authentication. Verify that the SAML response processing works correctly by checking System Logs > System Log > All for any SAML-related errors during the authentication process.

8

Test SSO functionality and validate attribute mapping

Perform comprehensive testing by initiating both SP-initiated and IdP-initiated SSO flows to verify bidirectional authentication works correctly. Test with multiple user accounts to ensure attribute mapping, user provisioning, and role assignment function as expected. Monitor the System Logs during test authentication attempts to identify any certificate validation issues, attribute mapping problems, or user provisioning errors. Validate that logout functionality works properly by testing both local logout from ServiceNow and global logout initiated from PingFederate to ensure proper session termination across both systems.

ServiceNow Script
// Script to test SAML attribute retrieval in ServiceNow
(function() {
    var gr = new GlideRecord('sys_user');
    gr.addQuery('user_name', 'test.user@company.com');
    gr.query();
    
    if (gr.next()) {
        gs.info('User found: ' + gr.name + ', Email: ' + gr.email);
        gs.info('Last login: ' + gr.last_login_time);
        gs.info('SSO Source: ' + gr.source);
        
        // Check user roles
        var roles = new GlideRecord('sys_user_has_role');
        roles.addQuery('user', gr.sys_id);
        roles.query();
        while (roles.next()) {
            gs.info('Role: ' + roles.role.getDisplayValue());
        }
    }
})();

Common Use Cases

Enterprise SSO with Active Directory integration

Organizations use PingFederate connected to Active Directory to provide seamless SSO access to ServiceNow for all domain users. When users access ServiceNow, they're automatically redirected to PingFederate which authenticates them against AD and returns a SAML assertion with user attributes. ServiceNow processes the assertion and either logs in existing users or creates new user accounts with appropriate roles based on AD group membership. This eliminates the need for separate ServiceNow passwords and provides centralized access control through existing AD security groups and organizational units.

Just-in-time user provisioning for contractors

Companies leverage SAML attribute-based provisioning to automatically create ServiceNow accounts for contractors and temporary workers stored in external identity systems. PingFederate passes contractor-specific attributes like employment type, end date, and project assignments through SAML assertions to ServiceNow. ServiceNow's user provisioning logic creates accounts with appropriate access levels and automatic deactivation dates based on these attributes. This approach ensures contractors get immediate access to required ServiceNow functionality while maintaining security boundaries and compliance requirements for temporary access.

Multi-tenant ServiceNow access with attribute-based routing

Large enterprises use PingFederate to manage access to multiple ServiceNow instances or domains based on user attributes like business unit or geographic location. SAML assertions include organizational attributes that ServiceNow uses to determine user roles, visible applications, and data access permissions within the platform. The integration supports complex attribute mapping scenarios where user privileges are dynamically assigned based on combinations of department, job title, and security clearance levels. This enables a single ServiceNow instance to serve multiple business units while maintaining appropriate data segregation and access controls.

Federated identity for merged organizations

Following mergers or acquisitions, organizations use PingFederate to federate multiple identity sources into a unified ServiceNow access model. Users from different legacy identity systems authenticate through their respective directories while PingFederate normalizes and maps attributes to consistent ServiceNow user profiles. The integration handles complex scenarios where users may exist in multiple source systems, requiring attribute precedence rules and conflict resolution logic. This approach allows organizations to provide immediate ServiceNow access to all users while gradually consolidating identity management infrastructure over time.

Compliance-driven audit logging and session management

Highly regulated industries leverage the PingFederate integration to implement comprehensive audit trails and session management for ServiceNow access. SAML assertions include compliance-specific attributes like security clearance levels and training certifications that determine user access to sensitive ServiceNow applications and data. The integration logs all authentication events, attribute changes, and role assignments for regulatory reporting and security analysis. Advanced configurations include session timeout policies, step-up authentication requirements for privileged operations, and automatic access revocation based on attribute changes in the authoritative identity source.

Troubleshooting

SAML assertion signature verification failed

Check that PingFederate's signing certificate is correctly imported into ServiceNow's Identity Provider configuration and hasn't expired or been renewed. Navigate to System Logs > System Log > All and search for 'SAML' to find detailed certificate validation error messages. Export the current certificate from PingFederate metadata and compare with the certificate stored in ServiceNow, updating if necessary. Ensure that the certificate chain is complete and that ServiceNow trusts the certificate authority if using enterprise PKI certificates.

User authentication succeeds but no ServiceNow account is created

Verify that the 'Create User' option is enabled on the Identity Provider record and that the User Field attribute mapping correctly maps to the 'User ID' field in ServiceNow. Check the SAML assertion in System Logs to ensure required attributes like email and user_name are being sent by PingFederate with populated values. Navigate to Multi-Provider SSO > User Provisioning Logs to review any errors during user creation, particularly around duplicate email addresses, invalid characters in usernames, or missing required fields. Ensure the default role assigned to new users exists and is active in ServiceNow.

Infinite redirect loop between ServiceNow and PingFederate

This typically occurs when the ServiceNow Entity ID or Assertion Consumer Service URLs don't match between the systems' metadata configurations. Verify that the Entity ID in PingFederate's SP connection exactly matches ServiceNow's entity ID in its metadata file, including any trailing slashes or URL parameters. Check that ServiceNow's 'Login URL' field on the Identity Provider record points to the correct PingFederate SSO endpoint and doesn't create circular references. Review both systems' logs simultaneously during a failed login attempt to identify which system is initiating the problematic redirect and adjust the configuration accordingly.

Attribute values not populating in ServiceNow user profiles

Examine the raw SAML assertion in ServiceNow's system logs to verify that PingFederate is sending the expected attribute names and values in the assertion. Check that ServiceNow's attribute mappings use the exact case-sensitive attribute names as they appear in the SAML response, not the friendly names shown in PingFederate's interface. Navigate to the Identity Provider record and verify that attribute mappings are configured with the correct target fields and that the 'Update User' option is enabled if you want to update existing user profiles. Test attribute fulfillment in PingFederate using the connection tester to ensure attributes are being populated from your data sources before being sent to ServiceNow.

SSO works but logout doesn't terminate PingFederate session

Configure Single Logout (SLO) by ensuring both ServiceNow and PingFederate have SLO endpoints properly configured in their respective metadata and that SLO is enabled in PingFederate's SP connection settings. Verify that ServiceNow's 'Logout URL' field on the Identity Provider record points to PingFederate's SLO endpoint and that the logout binding method matches between both systems. Check firewall and network connectivity to ensure ServiceNow can reach PingFederate's SLO endpoint for back-channel logout requests. Test both user-initiated logout from ServiceNow and global logout scenarios to ensure proper session termination across all federated applications.

Clock skew causing SAML assertion timestamp validation failures

SAML assertions have built-in timestamp validation that can fail if system clocks between ServiceNow and PingFederate are significantly different, typically more than 5 minutes apart. Verify that both systems are synchronized to the same NTP time source and check the current time on both systems during troubleshooting. Review ServiceNow's system properties for SAML timestamp tolerance settings and adjust if necessary while maintaining security best practices. Monitor the System Log for specific timestamp validation error messages that indicate whether the assertion is being rejected as too old or from the future, then correct the time synchronization accordingly.

Pro Tips

  • Configure SAML assertion encryption in PingFederate for sensitive environments by enabling assertion encryption in the SP connection settings and ensuring ServiceNow's private key is properly configured for decryption. This adds an extra layer of security for SAML attribute transmission and is often required for compliance in healthcare or financial services organizations.
  • Implement custom user provisioning scripts in ServiceNow to handle complex business logic like automatic group assignments, approval workflows for new user creation, or integration with HR systems for employee validation. Use the User Provisioning Script field on the Identity Provider record to execute custom GlideScript logic during the JIT provisioning process.
  • Set up SAML attribute-based access controls by creating User Criteria records that automatically assign roles and restrict application access based on attributes passed in SAML assertions. This enables dynamic privilege management where user permissions automatically adjust based on changes in the authoritative identity source without manual intervention.
  • Configure multiple Identity Provider records in ServiceNow for different user populations or testing scenarios, using the 'Domain' field to segregate users and the login URL parameters to direct specific user groups to appropriate PingFederate connections. This approach supports complex enterprise scenarios with multiple business units or testing requirements.
  • Enable detailed SAML debugging by setting the 'glide.authenticate.sso.debug' system property to true temporarily during troubleshooting, which provides verbose logging of SAML processing including assertion contents and attribute mapping results. Remember to disable debug logging in production environments to avoid performance impact and sensitive data exposure in logs.
  • Implement SAML assertion caching strategies by configuring appropriate session timeouts and considering PingFederate's assertion lifetime settings to balance security requirements with user experience. Shorter assertion lifetimes increase security but may require more frequent re-authentication, while longer lifetimes improve usability but extend the window for potential security issues.

Known Limitations

  • ServiceNow's Multi-Provider SSO plugin doesn't support SAML 2.0 artifact binding, only POST and Redirect bindings, which may limit integration options with some PingFederate configurations that require artifact resolution. Organizations requiring artifact binding must implement custom SAML processing or consider alternative integration approaches.
  • The native SAML integration doesn't provide real-time user deprovisioning capabilities, meaning user accounts disabled in PingFederate or upstream identity sources won't be automatically deactivated in ServiceNow. Organizations must implement separate user lifecycle management processes or custom scheduled jobs to synchronize user status changes.
  • ServiceNow's attribute mapping capabilities are limited to simple one-to-one field mappings and don't support complex attribute transformation, concatenation, or conditional logic without custom scripting. Advanced attribute processing requirements often necessitate custom User Provisioning Scripts or Business Rules to achieve desired user profile management.
  • SAML assertion processing performance can be impacted in high-volume environments with large attribute sets or complex user provisioning scripts, potentially causing authentication delays during peak usage periods. Organizations should monitor authentication response times and optimize attribute mappings and provisioning logic accordingly.
  • The integration doesn't support dynamic service provider metadata updates, requiring manual reconfiguration in both ServiceNow and PingFederate when instance URLs, certificates, or endpoints change. This can complicate disaster recovery scenarios or instance migrations that involve URL changes.

Frequently Asked Questions

Can ServiceNow act as both SAML Identity Provider and Service Provider simultaneously?

Yes, ServiceNow can function as both IdP and SP concurrently using the Multi-Provider SSO plugin for incoming federation and the SAML 2.0 Identity Provider plugin for outbound federation to other applications. This configuration is common in complex enterprise environments where ServiceNow federates with upstream identity providers like PingFederate while also providing SSO services to downstream applications. You'll need to configure separate certificates and endpoints for each role, and ensure proper metadata exchange with all federated partners.

How does ServiceNow handle SAML NameID format mismatches with PingFederate?

ServiceNow's SAML processing is flexible with NameID formats and will typically accept whatever format PingFederate sends, mapping the NameID value to the configured User Field regardless of format. However, consistency is important for user matching - if PingFederate sends email format NameIDs, ensure your ServiceNow User Field mapping points to the email field rather than user_name. You can configure the preferred NameID format in PingFederate's SP connection settings to maintain consistency, and ServiceNow will process unspecified, email, or persistent formats appropriately.

What happens to existing ServiceNow local accounts when SAML SSO is enabled?

Existing local accounts continue to function normally and users can still authenticate using local credentials unless explicitly disabled through user record configuration or system properties. ServiceNow maintains a 'Source' field on user records that distinguishes between local, SAML, LDAP, and other authentication sources. To force SAML-only authentication, you can set the 'glide.authenticate.sso.redirect.idp' property to automatically redirect all users to your IdP, though admin accounts should retain local login capability for emergency access through the direct login URL.

Can multiple PingFederate environments integrate with a single ServiceNow instance?

Yes, ServiceNow supports multiple Identity Provider configurations simultaneously, allowing integration with separate PingFederate environments for development, testing, and production, or different business units. Each Identity Provider record in ServiceNow has a unique configuration including its own metadata, certificates, and attribute mappings. You can use domain separation, user criteria, or custom login URLs to route different user populations to appropriate PingFederate environments. This approach is commonly used for staged deployments or multi-tenant scenarios.

How are ServiceNow user roles managed when using PingFederate SAML integration?

ServiceNow role assignment with SAML can be handled through default roles on the Identity Provider record, User Criteria records that map SAML attributes to roles, or custom User Provisioning Scripts for complex logic. PingFederate can send group membership or role attributes in SAML assertions that ServiceNow processes to automatically assign appropriate roles. Role updates can occur on each login if 'Update User' is enabled, allowing dynamic privilege management based on changes in upstream identity sources. Advanced scenarios often combine multiple approaches using default roles for baseline access and attribute-based assignment for specific privileges.

What certificate management considerations exist for ServiceNow PingFederate integration?

Certificate management is critical for secure SAML federation and requires attention to both signing and encryption certificates in both systems. ServiceNow imports PingFederate's signing certificate through metadata upload or manual configuration, while PingFederate may need ServiceNow's certificate for assertion encryption if configured. Certificate expiration monitoring is essential since expired certificates cause immediate authentication failures. Consider implementing certificate auto-renewal processes and maintain backup certificates for zero-downtime certificate rotation, especially in production environments where authentication availability is critical.

How does the integration handle network outages or PingFederate unavailability?

When PingFederate is unavailable, users attempting SSO will encounter authentication failures and may be unable to access ServiceNow if automatic redirection is configured. ServiceNow doesn't provide automatic failback to local authentication during IdP outages unless users access the direct login URL (https://instance.service-now.com/login.do). Organizations should implement monitoring for PingFederate availability and consider maintaining emergency admin accounts with local authentication capabilities. High-availability PingFederate deployments with load balancers and clustering help minimize authentication service interruptions and ensure business continuity.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue