Service Portal: After enabling Multi-Provider SSO, end users are able to access navpage.do through OKTA if they are already logged inIssue If customer has Multi-Provider SSO enabled, end users without roles may be redirected to the platform UI "navpage.do" through OKTA IdP-initiated login, instead of being redirected to Service Portal, if they click the ServiceNow tile on Okta while having an existing logged-in session to the ServiceNow instance. Steps to reproduce: Navigate to an SSO enabled instance.This will prompt user to the OKTA login.Login to OKTA with an end-user's credentials (user with snc_internal role).Once successfully logged, user will get to the OKTA homepage.From the OKTA homepage, click on the "instance-name" tile.This will redirect the user to https://instance-name.service-now.com/spNow close this tab and navigate back to the OKTA homepage.Click on the same "instance-name" tile again.User will be redirected to https://instance-name.servicenow-now.com/navpage.do Expected behavior: End users should be navigated to Service Portal https://instance-name.service-now.com/sp the second time and every time after logging in, when they click on the OKTA tile. Actual Behavior: It is redirecting properly to "/sp" portal only at first login.ReleaseServiceNow Utah and older releases. This problem should be fixed in the Vancouver release.CauseThe cause of this behavior is a current limitation in that when the SSO IdP doesn't set the relaystate parameter (which directs the instance where to send the user after login) the instance defaults to /navpage.do. When a user is already logged into the instance and subsequently clicks on the Okta 'tile' the instance doesn't re-authenticate the user, so the relaystate parameter is not used. This is documented as PRB1254142.ResolutionFix A fix for PRB1254142 is in the Vancouver release. In Vancouver and newer setting the System Property glide.authenticate.honor.relaystate.for.loggedin.sessions to true will ensure that the script in System Property glide.entry.first.page.script is run when the relaystate parameter is empty. Workarounds Set Okta to Always Set Relaystate on IdP-Initiated Sessions Okta can be set to always set a relaystate parameter for IdP-initiated sessions. This will ensure any user who clicks on the ServiceNow 'tile' in Okta (which triggers an IdP-Initiated session, including authentication if no existing session) will be redirected to the URL in the relaystate. It's not flexible though as will apply to all users. To set it do: On the ServiceNow instance create/set System Property glide.authenticate.honor.relaystate.for.loggedin.sessions as type true|false value trueOn the Okta admin interface go to Applications->Applications->(click the relevant ServiceNow UD app)->Sign On->Edit UI Script Workaround A more flexible workaround for this type of issue is to create a UI Script. The purpose of the UI Script is to check the roles of the logged in user and redirect them back to Service Portal if they don't have any roles. Some of the guidelines for the UI Script: Ensure that it is marked as Global. (Check the 'Global' Checkbox).This should always be tested on a sub-production first, before implementing in production.This workaround is not provided by development, so it is not fully supported. It is only created to provided temporary relief until development comes up with a decision.For the UI Script provided below, the instance-name should be switched with customer's instance name, and "/sp" should be switched with customer's portal name.Customer will have to create this script for each of their instances, keeping point #4 in mind. Here is a sample UI Script that can be used: addLoadEvent(ESSUserRedirect); function ESSUserRedirect() { if (g_user.userName != 'guest' && !g_user.hasRoles()){ if(document.URL.indexOf('sp')==-1) { if(document.URL.indexOf('instance-name.service-now.com')>=0){ top.location = "https://instance-name.service-now.com/sp"; } }} } Related Linkshttps://community.servicenow.com/community?id=community_blog&sys_id=cbcda2e9dbd0dbc01dcaf3231f961949