ServiceNow SSO: Sign In to ServiceNow Through SSOGEN

ServiceNow SSO with SSOGEN puts SSOGEN in charge of who signs in and how strongly. The application receives a signed SAML assertion, and you control access, policy and testing from the SSOGEN Admin Console.

Try it on your systems

ServiceNow SSO with SSOGEN gives your service desk one sign-in, governed by the policy you choose. ServiceNow is the service provider (SAML) or the client (OpenID Connect), and SSOGEN is the identity provider. SSOGEN connects any application that speaks SAML 2.0 or OpenID Connect this way, with no catalog entry needed.

This guide lists the values to copy between the two screens, then the steps to register, test and activate. The ServiceNow administration screen uses its own labels, so match fields by meaning with the table below.

Values to copy for ServiceNow

SSOGEN field or value	Vendor-neutral name in the application	Direction
Service provider entity ID	Entity ID, identifier, audience	From ServiceNow into SSOGEN
Assertion consumer service URL	ACS URL, reply URL	From ServiceNow into SSOGEN
Single logout URL (optional)	Logout URL	From ServiceNow into SSOGEN, if it has one
IdP entity ID	Identity provider entity ID, issuer	From SSOGEN into ServiceNow
Single sign-on URL	Sign-in URL, login URL	From SSOGEN into ServiceNow
Signing certificate	Identity provider certificate	From SSOGEN into ServiceNow
Name ID	User matching attribute	Choose in SSOGEN, set the same format in ServiceNow

If ServiceNow publishes a metadata file, upload it in the Connection step, and SSOGEN fills in the first three rows. In the other direction, importing SSOGEN’s metadata address configures the last four rows at once, including the certificate.

Requests and approvals start in a service desk tool, so its sign-in policy usually requires more than a password. SSOGEN policies are named and shared, so several applications use the same one.

Create a policy that requires a second factor.
Choose it on the application’s Authentication tab.
Use What if to see the outcome for a particular person without signing anyone in.

If a person signed in more weakly than the policy requires, SSOGEN asks for the second factor first and then continues to the application.

Register, assign, test and activate

In the Admin Console, open Applications, then SAML (or OpenID Connect) and start the registration wizard.
Fill in General and Connection with the values above, choose a Sign-in policy, and set Identify the person by.
Enter the Launch URL, the address that starts the application’s own SSO sign-in. Selecting Next saves the application, but it stays unavailable.
Assign a person or group, run Test for a named person, and review the result.
Select Activate application. The application then appears in My Apps for the people assigned to it.

The full screens and every message appear in Register a SAML application and Register an OpenID Connect application. The test and activation details appear in Assign people, set the sign-in policy, test and activate.

Questions people ask

What does ServiceNow need from SSOGEN?

The identity provider entity ID, single sign-on URL and signing certificate, or the metadata address that carries all three.

What does SSOGEN need from ServiceNow?

Its service provider entity ID and assertion consumer service URL, or its metadata file, plus a launch URL that starts the sign-in.

Why does a direct visit to SSOGEN’s sign-on address fail?

SSOGEN starts a SAML sign-in only when the application sends a request. My Apps must therefore open the application’s own sign-in address.

Where to go next

Return to the hub. The SSO applications hub has the protocol comparison and the other guides.
Choose the protocol. If you are not sure whether ServiceNow belongs under SAML or OpenID Connect, read Choose how to connect an application.
See it working. To see ServiceNow SSO and the second-factor policy working end to end, request a trial from the SSOGEN team.