SAML 2.0 - need help with RelayState issue - not working when a session is already open

[Tom Sienkiewicz]

Hi,

We have SAML 2.0 configured (client uses ADFS 2.0) to include a relay state in the URL. The problem is with deep linking from email notifications.

What happens is, if the user does not have a browser open / ServiceNow session running - they get authenticated properly and taken to the deep link page (in this case, my_approvals in service portal). However, if they already did that once or simply have SN open in a browser, any subsequent link from notification ends up on the main page instead of the correct deep link page.

It looks like the Relay State is only processed correctly the first time and any subsequent links get 'trimmed'... it is beyond my level of competence regarding ADFS so any help would be greatly appreciated.

The link in the notification is constructed as below (<> are replaced with real values of course):

https:// adfs.<CLIENTNAME>.ag/adfs/ls/IdpinitiatedSignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252F<INSTANCE>.service-now.com%26RelayState%3Dhttps://<INSTANCE>.service-now.com/service_management/my_approvals.do

Any suggestions? thanks a lot!

[dklimas]

Hello Tomasz,

Did you find a resolution to this issue?

[Tom Sienkiewicz]

Hi David,

I believe it was due to the client not using the latest version of SSO plugin but unfortunately haven't got any specifics. Will let you know if I hear something more.

[laurelin]

Several years later, we have the same problem, and have tracked it down to the fact that the SAML2_update1 script does "double encoding" of URLs.   It encodes URLs that have already been encoded (deep link URLs such as are sent in email, which already have URL encoding applied).   What happens is that the SAML2_update1 script encodes this already-encoded URL, then redirects to the login service provider, who (after authentication) in turn redirects you back to the relayState URL.   But now servicenow cannot parse this double-encoded URL, and dumps you on a home page by default because it can't figure out where you wanted to go.

I don't have a good solution.   Servicenow has been very much less than helpful on this.

[Tom Sienkiewicz]

Thanks for sharing Lauri. It's good to know, you would probably be able to fix that by customizing that script to prevent double encoding. Have you tried to check if there are newer updates out there?