ServiceNow SSO with MojoAuth

Connect your ServiceNow instance (the Now Platform) to MojoAuth using SAML 2.0. MojoAuth acts as the Identity Provider (IdP); ServiceNow acts as the Service Provider (SP). Once configured, users can sign in to ServiceNow with SP-initiated login (from the ServiceNow login page) or IdP-initiated login (from your MojoAuth-hosted login page or an app launcher).

How it works

Prerequisites

• A MojoAuth project (test or live) with admin access to Developers → Applications.
• A ServiceNow instance with admin (or security_admin) role access.
• The Integration - Multiple Provider Single Sign-On Installer plugin activated on your instance (this ships with most editions but is not active by default — see Step 2).
• Decide up front which ServiceNow user field will match the identity MojoAuth sends (user_name or email), and make sure existing ServiceNow user records populate that field consistently.

Step 1 — Create the MojoAuth SAML connection

1. In the MojoAuth dashboard, go to Developers → Applications → New Application → SAML 2.0 SSO.
2. Enter a connection name (e.g. ServiceNow – Production) and click Create connection. This creates a draft connection and auto-issues a signing certificate.
3. Leave this tab open — you'll come back to copy the IdP metadata URL and, later, paste ServiceNow's SP details.

See SAML SSO Connections for the full concept walkthrough.

Step 2 — Activate multi-provider SSO in ServiceNow

{BASE}/saml/{projectId}/sps/{spId}/metadata

Step 3 — Give ServiceNow's SP details back to MojoAuth

Back on the MojoAuth SAML connection page:

1. Use Import from metadata if ServiceNow exposes an SP metadata endpoint on your instance, or choose Manual configuration and enter:
   • SP Entity ID: https://<instance>.service-now.com
   • ACS URL: https://<instance>.service-now.com/navpage.do
2. Set NameID format to emailAddress if you'll match on email, or unspecified/persistent if you'll match on user_name — this must agree with the user field you pick in ServiceNow's IdP record (see Step 4).
3. Click Save.

Step 4 — Attribute mapping and user lookup

ServiceNow's SAML IdP record has a User Field setting that tells it which local user table column to match the incoming NameID (or a mapped attribute) against — typically user_name or email.

Configure on the MojoAuth connection's Attribute mappings section:

• If ServiceNow's User Field is set to email, set the connection's NameID format to emailAddress and map source: email so the subject itself carries the address ServiceNow looks up.
• If matching on user_name, map a source: identifier (or userId, depending on how your directory populates ServiceNow's user_name) to the NameID, and set NameID format to unspecified or persistent.
• Add the User.Email, User.FirstName, User.LastName attribute rows above if you want ServiceNow to refresh profile fields on login (requires JIT/auto-provisioning or an existing matching user record).

Step 5 — Test

1. On the ServiceNow IdP record, click Test Connection. ServiceNow performs an SP-initiated SAML round trip against MojoAuth and reports whether the assertion validated.
2. From the MojoAuth connection page, use Test SSO to run an IdP-initiated login and confirm a valid signed assertion reaches ServiceNow's ACS URL.
3. Once both pass, open the IdP record and check Active, then set it as the default provider only after confirming regular users can sign in end-to-end — test with a non-admin account in an incognito/private browser window first, keeping your own admin session on local login.
4. Visit https://<instance>.service-now.com/navpage.do in a private window to trigger SP-initiated login and confirm the redirect to MojoAuth and back works.

Troubleshooting

"Certificate validation failed" / signature mismatch The X.509 certificate on the ServiceNow IdP record doesn't match MojoAuth's current signing certificate. Re-copy the PEM from Copy PEM on the MojoAuth connection page (certificates rotate periodically) and update the ServiceNow IdP record, or re-run Import Identity Provider Metadata to refresh it automatically.

User not found / "no local user found for NameID" errors ServiceNow's IdP record User Field doesn't match what MojoAuth is sending in the NameID. Confirm the connection's NameID format and mapped source (Step 4) correspond to a real, populated field (user_name or email) on the target sys_user record. Check System Logs → System Log → All and filter for SAML for the specific rejection reason.

Locked out after setting the provider as default If a misconfigured IdP becomes the default and blocks admin login, browse to https://<instance>.service-now.com/login.do?local_login=true to bypass SSO and sign in with a local account, then fix or deactivate the IdP record. Always verify the connection with a non-admin test user before flipping Active/default on for everyone.

ACS URL mismatch / "Invalid Destination" error The ACS URL entered on the MojoAuth connection doesn't exactly match what ServiceNow expects (https://<instance>.service-now.com/navpage.do for most instances, though some configurations use a different path). Recheck the SP Configuration fields on the ServiceNow IdP record and re-paste the exact value into MojoAuth's ACS URL field.

"Entity ID mismatch" / audience restriction errors The SP Entity ID saved in MojoAuth doesn't exactly match the Issuer/audience ServiceNow sends in its AuthnRequest (https://<instance>.service-now.com, case- and trailing-slash-sensitive). Copy it directly from the ServiceNow IdP record's SP Configuration section rather than typing it by hand.

SSO works but attributes (name, email) don't update ServiceNow only updates profile fields on login if the corresponding attribute mapping rows exist on the MojoAuth connection and your instance's SSO properties allow attribute-based updates. Add the User.Email / User.FirstName / User.LastName rows from Step 4 and confirm they're received by checking the SAML response in ServiceNow's System Logs.

Related docs

• SAML SSO Connections
• Managing Applications
• Integration Guides overview