'login_with_sso.do' and relay state

[jorgegrc]

Some of our Service Portal pages are public and I am trying to set a relay state so users are redirected to the same page they were in after they hit the "login" button.

ServiceNow, using the "Login" widget, redirects the user to the following URL:

"/login_with_sso.do?glide_sso_id=<sys_id_of_your_default_idp>"

Does anybody know if it is possible to add any parameter to that URL so that the UI Page (login_with_sso) will pick it up and use it as the RelayState param for the SSO?
I have already checked old threads about this but unfortunately nothing worked as they were appending "/nav_to.do?uri=" to the URL, so you get the instance frame and everything displayed once you're redirected.

This works seamlessly within the tool, but as soon as you try to integrate the Service Portal with a SSO login it starts not being that easy.

EDIT:

I know I can modify the SSO Script that the Multi-Provider SSO plugin provides for authenticating and try to do the trick there. For this we need to identify when users come from the portal and then setting the relay state using the overridable method for it. 

This workaround is not desirable as I guess it should be doable form the Login widget... only keeping that as a last resort if nothing else works.

EDIT2:

Just found that the script include SAML2_update1 explicitly prevents deep linking (or generating a Relay State) if the URL from which you're attempting to redirect the user to the SSO login page contains 'login_with_sso'.

Thanks in advance,

Jorge

[jorgegrc]

Thanks Drew, this is exactly what I cannot achieve. Any hints? To redirect the user to a SSO IdP page you need to access through login_with_sso afaik. And I cannot pass this top secret UI Page any relay state.

Came to my mind now that maybe I can add the SSO id param to the URL and ServiceNow might recognize it and redirect to the IDP. In any case this looks very much like a hack and I'd like to find a better more sustainable solution.

[DrewW]

Have you used the "glide_sso_id=provider_sys_id" and then made sure that ServiceNow is passing relaystate to the sso provider and the SSO provider supports it?  

Have you tried going to the SSO provider Admin and asking for a URL that will cause a user to be authenticated and sent over to ServiceNow?  You could just add the relaystate parm to that and see what it does.

[ajs4]

Hi @jorgegrc  / @DrewW / @Prateek kumar 

Please can you say did we achieved the requirement.
We're also came to similar type of situation

[jorgegrc]

The relay state is kept by ServiceNow OOB since a few versions already. At least for us when we moved from SAML to OIDC, it worked more or less well without the need for many adjustments.

The only thing we did after moving to OIDC is to override the 'process()' and 'loginUser()' methods from the Script Include 'MultiSSO_OIDC_internal'. For this you can use the provided 'MultiSSO_OIDC_custom' script include, but watch out for upgrades as you might miss OOB changes to the original "MultiSSO_OIDC_internal" script as you won't have collisions if you use the custom one to extend it.

The Relay State and deep linking happen on the 'loginUser()' method, so have a look there, it should be working more or less out-of-the-box.

Good luck!