ADFS Relay State URL encoding

[BobKendall]

We are looking for some advice for how to encode a URL with a RelayState so it can be properly processed by ADFS.

We are configuring the ADFS and Service-Now to enable deep linking of embedded links in notifications messages to work even if the user is not authenticated. This would use the RelayState functionality built into the URL's sent between Service-Now and ADFS. Using the latest verision of ADFS and multiSSO for Service-Now, Service-Now has successfully generated the URL with the embedded RelayState. Unfortunately, ADFS does not fully respond to this URL, because it is not encoded according to RFC 1738, Uniform Resource Locators (URL) specification. If we encode the URL manually and place it in a browser, the user is authenticated and redirected to the desired link. We believe that the ADFS IIS server needs to be enabled to do this encoding step automatically and send the result to the ADFS server, but we have not found the needed steps to configure the encoding process.

Has anyone encountered the issue of enabling URL encoding on IIS so the ADFS server can properly respond to the RelayState redirection request? Also, what would be the necessary configuration steps?

We have done a good bit of research for the easy answers, but if anyone can help us to the correct direction, it would be appreciated.

Regards,

Bob

[dsnyder]

We have the same problem. We found this link and have asked ServiceNow for support to determine a complete list of the steps:

http://www.confusedamused.com/notebook/adfs-relaystate/ 

[john_andersen]

People do deep linking with ADFS using the RelayState for ServiceNow all the time. Here is a quick little link that explains the nav_to.do page used in creating RelayStates and deep links in ServiceNow: http://www.john-james-andersen.com/blog/service-now/deep-link-generator.html

[BobKendall · Accepted solution]

The final solution to this problem was to upgrade both the ADFS and Service-Now system to their latest versions. For ADFS, this is ADFS 2.0 Update Rollup 2 and for Service-Now, this is update set MultiSSO - Pre Calgary (Revised 2013-09). We use the multi-tenant version of SSO from Service-Now. We also configured the SAML2 Update1 Properties. With this the SSO process for authentication worked as expected.

For the deep linking to work, one business rule, MultiTenant SSO identify company, had to be changed/fixed so that the URL embedded in the email had the related company Sys_Id in the parameter list. For multi-tenant implemenation, the &com (for company) parameter is needed in the ${URI} parameter for the correct property set to selected when doing the redirection for deep linking. This was recognized as a bug and Service-Now is to update the business rule in the standard code base.

With this approach the ADFS and deep linking functionality fully work and the whole encoding problem is a non-issue.

[poyntzj]

We are using ADFS Rollup 2 and the SAML2 Update 1

The URL links are correct and work if the user has an established session in Servicenow.

If the user does not have an established session then our users click on the link, their browser loads, they wait a short period of time and are then either taken to the Portal page or their dashboard depending on the user and roles and not the intended target record.

I am seeing mention of using idp initiated logon, but not sure how to get the url's encoded at the moment or how we would get the system to automatically use this in the ${URL_REF} variable in the notifications.

I have not found anything that talks about idpinitiated login bar one brief mention during "debugging" and not found anything that talks about generating the encoding as mentioned here

http://social.technet.microsoft.com/wiki/contents/articles/13172.ad-fs-2-0-relaystate-generator.aspx