ServiceNow Okta integration

• ServiceNow: admin, and the Multi-Provider SSO plugin activated.
• Okta: a Super Admin and the ServiceNow app from the Okta Integration Network (OIN).

Two things are worth settling before touching either system, because both are difficult to change afterwards.

Which system owns the user record. Okta is the identity provider, so it should own identity attributes: name, email, employee identifier, manager. ServiceNow owns what is specific to the platform: roles, groups used for assignment, preferences. If both write the same attribute, one will overwrite the other on a schedule and nobody will be able to say which is right.

How users are matched. There must be one attribute that identifies the same person in both systems and does not change. Email address is the usual choice and it is a poor one, because people change names. An employee identifier is better where one exists. Getting this wrong produces duplicate users, which is tedious to unpick once records reference them.

• In Okta, add the ServiceNow app (OIN), set your instance subdomain, and choose SAML 2.0.
• In ServiceNow Multi-Provider SSO → Identity Providers, import Okta's metadata XML.
• Set the NameID to email/user_name and test with Test Connection before enabling.
• Activate the IdP and set default; keep a local admin login (/side_door.do) as a fallback.

Worth understanding what the exchange actually does, because it makes the failures readable. The user hits ServiceNow, which does not know them, so it redirects to Okta with a request. Okta authenticates the person however it chooses, and sends back a signed assertion saying who they are. ServiceNow checks the signature against the certificate it holds, reads the identifying attribute, and finds the matching user record.

So there are only a few places it can break: the redirect, the signature, the attribute, or the lookup. That is why SSO problems have a small number of causes and why the error usually names one.

The single most important precaution: keep a local login route working while you configure this, and know the URL that bypasses SSO. Misconfigured single sign on locks everybody out including you, and recovering without that route means a support case rather than a correction.

• In the Okta app, open Provisioning → Integration and enable API integration.
• Provide the ServiceNow SCIM base URL and a service account credential (or OAuth).
• Turn on Create Users, Update Attributes, Deactivate Users.

The mental model for provisioning is that Okta pushes and ServiceNow receives. Create, update and deactivate are pushed as they happen, so ServiceNow does not poll and there is no import schedule to monitor. That is simpler than the alternative and it means a failure is silent on the ServiceNow side: nothing arrived, and nothing was expected.

Group push is the piece worth planning. Okta groups can create and maintain ServiceNow groups, which is attractive, and it also means your group structure is now defined in Okta. Decide deliberately which groups are pushed and which remain platform owned, because assignment groups are usually the second kind and directory groups the first.

The habit that makes this straightforward is refusing to test SSO and provisioning together, because their failures look identical from the outside.

1. Configure SSO first, with the bypass URL open in a second browser profile.
2. Test with a user that already exists in both systems, matched on your chosen attribute. Success here proves the assertion and the lookup.
3. Now break it deliberately: change the identifying attribute on one side and read the error. That error message is the one you will see in production, so learn it now.
4. Only then configure provisioning. Create a new user in Okta and watch the record appear.
5. Change an attribute in Okta and confirm it updates, rather than creating a second record.
6. Deactivate the user in Okta and confirm what happens in ServiceNow. This is the step teams skip and it is the one auditors ask about.

Step six deserves a decision rather than a default. Deactivation should lock the account, and it should usually not delete the record, because that record is referenced by every incident the person ever touched.

Okta profile        ServiceNow (sys_user via SCIM)
userName        ->  user_name
email           ->  email
firstName       ->  first_name
lastName        ->  last_name
groups          ->  group membership -> roles

Two rules keep an attribute map maintainable. Map the minimum: every attribute you push is one more thing that can be wrong, and most ServiceNow processes need far fewer user fields than people assume. And map references carefully: a manager field is a reference to another user record, so it only resolves if that person has already been provisioned. New starters whose manager joined the same week are the case that exposes this, and the symptom is an empty manager field on exactly the records where somebody needed it.

• Push Okta groups to ServiceNow and map them to groups/roles, so access is driven by Okta membership.

The pattern worth following is that Okta groups drive ServiceNow groups, and ServiceNow groups grant roles. Mapping a directory group directly to a role works and it puts your platform authorisation model inside the directory, where the people administering it do not know what the roles mean. One layer of indirection keeps the decision about what a role grants where the people who understand it can see it.

• Assign the app to a test user in Okta; confirm the ServiceNow user is created and can SSO in.
• Remove the assignment; confirm the user is deactivated.
• Only then enforce SSO for everyone.

Plan the cutover as a sequence rather than a switch. Run SSO for a pilot group first, with everybody else still on local authentication. Then widen it. Then enable provisioning for new users only, so mistakes affect people who have not started yet. Then bring existing users into scope. Each stage has a small population and an obvious way back, which is what you want the first time a real directory meets a real instance.

• SAML SSO failed: clock skew or NameID mismatch, check the assertion.
• Provisioning 401: SCIM service account lacks rights.
• Locked out: use /side_door.do local login to fix the IdP.

Three symptoms cover most cases and each has a different first check.

The login loop. The browser bounces between the two systems. Almost always a clock skew or a mismatch between the URL configured on each side, because an assertion issued for one address is not valid at another.

Authenticated but no user. The assertion arrived and was accepted, and no matching record was found. Your identifying attribute is different on the two sides for this person.

Worked yesterday, fails today. A certificate expired. This is the one to prevent rather than to fix, and preventing it means a reminder in a calendar somebody actually reads, because certificate expiry takes down every user at once.

Version note: both products change independently, and the integration is the join between them. The ServiceNow spoke for Okta, the SCIM implementation and Okta's own application catalogue have all been revised more than once, so an instruction naming a specific screen may be out of date on either side even when the protocols are unchanged. See the Slack integration, the Workday integration and the Dynatrace integration for the same patterns against other systems.

• No bypass route open during configuration. You lock yourself out.
• Matching on an attribute that changes. Duplicate users.
• Both systems writing the same attribute. It flips on a schedule.
• Never testing deactivation. The step the audit is about.
• Forgetting the certificate expiry date. Everybody is locked out on the same morning.

Wiring up single sign on takes an afternoon, and designing the ownership and matching so it still works after a reorganisation is the judgement the course builds.