Single Sign On Deep Linking Issue - RelayState not returning from IBM TFIM

[bennyb]

Hi,

thought I'd share the solution to a problem we were having with Single Sign on using SAML2 and IBM Tivoli Federated Identity Management (TFIM).

The issue was that when URLs to specific pages (deep links) within Service-Now were attempted to be navigated to, users were automatically redirected to the Service-Now homepage, as when passing through the SAML2 authentication process, the deep link would be lost.

Setting a RelayState parameter was documented to fix this issue. When we tried to append RelayState to the end of our baseUrl we found that TFIM would only return the baseURL - ie it seemed that TFIM was not reading the RelayState.

The problem turned out to be that our baseURL included the Target parameter. When leaving the Target parameter off the baseURL, RelayState was able to be returned by TFIM:


Originally, system property "glide.authenticate.sso.saml2.idp_authnrequest_url" included the parameter "Target".

https://mycompany-idp.com?RequestBinding=HTTPPost&NameIdFormat=email&PartnerId=https://mycompany.ser...

Leaving off the Target parameter resolved the problem:

https://mycompany-idp.com?RequestBinding=HTTPPost&NameIdFormat=email&PartnerId=https://mycompany.ser...

Hope this helps others as it is not clear in IBM TFIM documenation!

[antonymirza]

Hi Benny, We are also facing similar trouble in one of approval email notification but, I do not find any value in System Property (glide.authenticate.sso.saml2.idp_authnrequest_url) stored in our URL.

In our case, the company sys_id comes two times in the URI like this "https://mycompany.service-now.com/ess?companyID=c94993314a362312005cfc20c1aa15d2/approval.do?companyID=c94993314a362312005cfc20c1aa15d2"

Please let me know where else can we check and correct in ServiceNow?

[bennyb]

Hi AM,

there is a script include called "SAML2_update1" that comes with the SAML 2 plugin (I presume you have installed this to get SAML 2 setup).

Within this script include is a function called "generateRelayState" which performs the deep linking redirect. You could add some extra log statements in this to figure out what is happening.

However if it is just approval emails that are going wrong, it looks more like something is going wrong in your email notification. Take a look at this wiki page for more info:
http://wiki.servicenow.com/index.php?title=Email_Notifications#Enabling_Links_to_ServiceNow_Records_.28Deep_Linking.29

Cheers,
benny

[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.

[Inactive_Us2219]

Any chance you've run into a solution for this?  We're facing same issue and I'm trying to work it out now.

Thanks!