Multi-provider SSO, Okta, and thou

Go to solution
Uncle Rob
Kilo Patron

‎07-25-2017 09:54 AM

I'm trying to pull off an Okta integration via Multi-Provider SSO, but I'm having difficulty in two areas:

1)   Authentication

We created a dummy user on both ServiceNow and Okta, and the SSO component worked smooth.   So we attempted to test with a user that pre-existed in ServiceNow and now has an Okta user name.   In this case, the user will proceed immediately to log out (and sys logs will complain that the user was not found).   The user will log in perfectly if I dis-associate him from his company record in ServiceNow.     I know multi-provider SSO allows you to specify the SSO Source by company, but if the Company has no SSO source, should it not use the default?

Tests:

- User has no company defined in ServiceNow = login success!

- User has a company defined in ServiceNow + Company as SSO Source of Okta IdP's sys_id = fail (user not found)

- User has a company defined in ServiceNow + Company has no SSO Source defined + Okta IdP set as default IdP = fail (user not found)

2)   Provisioning

I had always assumed that with Multi-Provider SSO and Okta that you could provision users into ServiceNow if the SSO Source had validated them.   I was anticipating that on SN I could check a box to allow inserts (in the same fashion that multi-povider SSO allows updates)

find_real_file.png

However, when we create a user in Okta and grant access to SN, when that user attempts to log in they're taken directly to the logout screen.   System logs complain that the user does not exist.   Now, some peers are telling me that this happens via an Okta push vs a ServiceNow pull.   This thread seems to indicate that a pull is possible too.   What do you good folks generally see?

Preview file
7 KB
0 Helpfuls
  • 3,294 Views
1 ACCEPTED SOLUTION

Go to solution
Uncle Rob
Kilo Patron

‎07-28-2017 05:53 AM

UPDATE


Special thanks to ServiceNow support for the assist on this one.   Apparently there was a Before Query business rule on the User table that was interfering with multi-provider SSO's ability of looking up the User / User-Company necessary to determine SSO Source.   Once we refactored that business rule (for an ancient and no longer relevant use case) everything started working exactly as expected.



Lessons learned:   If you're working on a customer instance always recon for custom Before Query business rules.


View solution in original post

8 REPLIES 8

Go to solution
chris_snc_
ServiceNow Employee
ServiceNow Employee

‎07-26-2017 11:48 AM

If you have SAML debugging enable you would see the following -



When "SSO Source" is populated in the company record:



11:27:21.647InfoDefault-thread-25DCD1154CDBD08300DCA6FD441D96193E*** Script: Looking up user id : first.last@servicenow.com
11:27:21.647InfoDefault-thread-25DCD1154CDBD08300DCA6FD441D96193E*** Script: Looking up using user field : user_name
11:27:21.650InfoDefault-thread-25DCD1154CDBD08300DCA6FD441D96193E*** Script: Found SSO sso:46ce4dc############### for the user : first.last@servicenow.com from its company record
11:27:21.651InfoDefault-thread-25DCD1154CDBD08300DCA6FD441D96193E*** Script: Returing SSO IdP from company record: 46ce4dc###############
11:27:21.655InfoDefault-thread-25DCD1154CDBD08300DCA6FD441D96193E#12410 /xmlhttp.do -- total transaction time: 0:00:00.015, transaction processing time: 0:00:00.015, total wait time: 0:00:00.000, session wait: 0:00:00.000, semaphore wait: 0:00:00.000, source: 199.91.141.248, chars: 173, uncompressed chars: 190, SQL time: 1 (count: 6), business rule: 0 (count: 1), phase 1 form length: 0, largest chunk written: 163, request parms size: 408, largest input read: 0
11:27:21.708InfoDefault-thread-28DCD1154CDBD08300DCA6FD441D96193E#12411 /login_with_sso.do Parameters -------------------------
glide_sso_id=46ce4dc###############


When "SSO Source" is in the user record:



11:33:03.027InfoDefault-thread-270F23998CDBD08300DCA6FD441D961957*** Script: Looking up user id : first.last@servicenow.com
11:33:03.027InfoDefault-thread-270F23998CDBD08300DCA6FD441D961957*** Script: Looking up using user field : user_name
11:33:03.030InfoDefault-thread-270F23998CDBD08300DCA6FD441D961957*** Script: Found SSO sso:46ce4dc############### for the user : first.last@servicenow.com
11:33:03.031InfoDefault-thread-270F23998CDBD08300DCA6FD441D961957*** Script: Returing SSO IdP from user record: 46ce4dc###############
11:33:03.035InfoDefault-thread-270F23998CDBD08300DCA6FD441D961957#12489 /xmlhttp.do -- total transaction time: 0:00:00.019, transaction processing time: 0:00:00.019, total wait time: 0:00:00.000, session wait: 0:00:00.000, semaphore wait: 0:00:00.000, source: 199.91.141.248, chars: 173, uncompressed chars: 190, SQL time: 2 (count: 5), business rule: 0 (count: 1), phase 1 form length: 0, largest chunk written: 163, request parms size: 408, largest input read: 0
11:33:03.088InfoDefault-thread-280F23998CDBD08300DCA6FD441D961957#12490 /login_with_sso.do Parameters -------------------------
glide_sso_id=46ce4dc###############


When neither User or Company record has "SSO Source" defined but Identity Provider record is set as 'default':



11:35:31.664InfoDefault-thread-25E6B3D1CCDBD08300DCA6FD441D9619E6*** Script: Looking up user id : first.last@servicenow.com
11:35:31.664InfoDefault-thread-25E6B3D1CCDBD08300DCA6FD441D9619E6*** Script: Looking up using user field : user_name
11:35:31.669InfoDefault-thread-25E6B3D1CCDBD08300DCA6FD441D9619E6*** Script: Using default SSO: 46ce4dc###############


I would recommend creating a new incident ticket in HI and include the respective session logs from the failed login attempts so Support is able to determine the cause of the issue. Unfortunately, I was unable to replicate a login issue on my instance using my OKTA tenant with the above "SSO Source" configurations mentioned above.



Things to note:


The current "Servicenow - Eureka and later releases" application in OKTA uses a 'push' to create/update user records in the configured instance; it does not set the "SSO Source" field during the provisioning process.



Additionally, checking the "Update User Record Upon Each Login" or "Auto Provisioning User" checkboxes in the Identity Provider record does not trigger any configuration on the respective identity Provider. When checked, the instance will process the user information, when it exists, in the generated SAMLResponse.


Go to solution
Uncle Rob
Kilo Patron

‎07-28-2017 05:53 AM

UPDATE


Special thanks to ServiceNow support for the assist on this one.   Apparently there was a Before Query business rule on the User table that was interfering with multi-provider SSO's ability of looking up the User / User-Company necessary to determine SSO Source.   Once we refactored that business rule (for an ancient and no longer relevant use case) everything started working exactly as expected.



Lessons learned:   If you're working on a customer instance always recon for custom Before Query business rules.


Go to solution
Max C1
Giga Contributor
In response to Uncle Rob

‎01-09-2019 08:38 AM

Robert, Do you recall the name of this business rule? 

0 Helpfuls

Go to solution
Uncle Rob
Kilo Patron
In response to Max C1

‎01-11-2019 06:08 AM

It was a custom rule on that instance.

0 Helpfuls