issue with Okta SSO

[Justin scott1]

Hey guys

I am having an issue setting up OKTA sso in our test instance. This is working fine in prod and all the setting look the same in test other than the instance it points at in OKTA but when I test logging in it takes me into the OKTA app to select which app I want to access. As it does in production, it should authenticate and the re-direct to the test instance as I am logging into test. I have check with the OKTA guys and everything is correct their end. Has anyone else had this issue? any thoughts on what is causing this?

Thanks

[Community Alums]

Hi @Justin scott1 ,

Confirm that defaultRelayState URL is set properly to be redirected to a portal.
1) - Example SOO configuration in SAML.
SSO URL: https://<instance_name>.service-now.com/navpage.do
Default Relay State: https://<instance_name>.service-now.com/sp


2) Add the below system property:
name : glide.authenticate.honor.relaystate.for.loggedin.sessions
type: true|false
value : true

The above system property will ensure the defaultRelayState URL is always honored when the user clicks on Okta tile to access servicenow portal.

If you want to re-validate the integration, then refer : https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0777770

[Justin scott1]

Hey Sandeep,

Thankyou for the response looking at the SAML page to configure I don't see the SSO and default relay fields? I have the below. the sys property you mention does not exist so I can create one as you said above but I don't want to do that until I know what fields to populate on the below page

[Rajdeep Ganguly]

Here are some steps you can follow to troubleshoot the issue:

1. **Check the SSO Configuration in ServiceNow**: Ensure that the SSO configuration in your test instance matches the one in your production instance. This includes the Entity ID, Single Sign-On URL, and Single Logout URL.

2. **Check the OKTA Configuration**: Verify that the OKTA configuration for your test instance is correct. This includes the Assertion Consumer Service (ACS) URL, which should point to your test instance.

3. **Check the User Attributes**: Make sure that the user attributes in OKTA match the ones in ServiceNow. The most common attribute used for this is the email address.

4. **Check the Redirection URL**: Ensure that the redirection URL after successful authentication in OKTA points to your test instance.

5. **Check the SSO Logs**: ServiceNow provides SSO debug logs which can be very helpful in troubleshooting SSO issues. You can enable these logs by navigating to System Logs > Debug Logs in ServiceNow.

6. **Check the Network Traffic**: Use a tool like Fiddler or Chrome Developer Tools to inspect the network traffic during the SSO process. This can help you identify any issues with the SAML assertion or response.

7. **Contact ServiceNow Support**: If you're still unable to resolve the issue, consider reaching out to ServiceNow support for further assistance. They have access to more detailed logs and can provide more in-depth troubleshooting.

Remember, any changes made to the SSO configuration should be tested in a non-production environment first to avoid any potential impact to your users.

nowKB.com

For asking ServiceNow-related questions try this :
For a better and more optimistic result, please visit this website. It uses a Chat Generative Pre-Trained Transformer ( GPT ) technology for solving ServiceNow-related issues.
Link - https://nowgpt.ai/

For the ServiceNow Certified System Administrator exams try this :
https://www.udemy.com/course/servicenow-csa-admin-certification-exam-2023/?couponCode=NOW-DEVELOPER

[Justin scott1]

Thanks Rajeep. I will check through the above on Monday when the Okta admin is available to confirm config their side.

Thanks