Running Documaker Interactive in MS Edge with IE Mode

WIPEdit is a thick client that, in more recent versions, has two behaviors. In modern browsers, it lives up to its description as a thick client, because it runs entirely outside of the browser. However, when used with Internet Explorer, its behavior is a bit different. In IE, WIPEdit acts as a browser plugin, using ActiveX technology to provide document editing services. The benefit of this model is that it allows WIPEdit to function entirely in the context of the browser, which allows features like authentication and single sign-on (“SSO”) to work seamlessly. For implementations of newer versions WIPEdit you may have experienced some difficulties getting SSO to function properly, since WIPEdit in a modern browser does not use ActiveX, and therefore does not have the benefit of browser context for authentication functions like SSO. In those cases, you have likely been advised to continue using your applications with Internet Explorer, since the forthcoming patch for WIPEdit that supports authentication features like SSO in modern browsers is not expected until mid-2022. This presents a challenge for IT groups faced with transitioning from IE to Edge, especially when WIPEdit functionality is often involved in mission-critical business processes. Thankfully, Edge’s IE Mode provides a handy stopgap until the new WIPEdit patch is available. Let’s dig deeper into configuration and problem solving with this configuration.

Microsoft has provided a comprehensive guide for IE Mode setup and configuration within an enterprise, which is comprised of two general steps: create an Enterprise Mode Site List, and configure IE Mode in group policies. Typically, these steps will be completed by network or infrastructure administrators, rather than application administrators. After completing these steps, and adding the URL for your Documaker web application to the Site List, you should be able to access the application and single sign-on should work – right?

In our case, which prompted this post, the architecture includes a mix of Oracle Access Manager (“OAM”), Oracle WebGate, and NetIQ to provide identity, authentication, and authorization management controls. Documaker Interactive was already configured for SSO support in this environment, however, after completing the IE Mode setup, we found that the browser did not perform the single sign-on authentication. Instead, the login page was displayed, and it was not using Edge’s IE Mode (Edge displays an IE icon when a site is using IE Mode). At a high level, the authentication model for single sign-on involves a security token that is obtained when a user identity has been authenticated, and this token is used to determine if that user has authorization to a given application. The process of obtaining the token, validating the token, and authorizing the token’s access to a web application happens via a series of redirection requests between the browser and the web infrastructure. If you’ve ever visited a secure site where, after login, the browser appears to bounce between different URLs before arriving at your intended destination, you’ve likely experienced the authorization process.

After some initial investigation, we determined that our token was being rejected by the OAM routing rules, which are integral to enterprise application security. As stated above, your administrators should configure the Site List to include your application. An example entry for Documaker Interactive might look like this:

What we noticed in testing this configuration is that when the SSO redirection happens, IE Mode is not used for the redirected traffic, since it is only configured for the URL for /DocumakerCorrespondence. We see the link flashing in the address bar, and note that the login page is displayed, and does not present the IE Mode icon.

For IE Mode to work properly, all URLs for authentication and SSO services must be explicitly configured as neutral sites in the Site List. Otherwise, applications that would normally force Edge to IE Mode will instead open in Edge normally, and authentication will fail. A neutral site will allow traffic to use the same browser mode where the navigation started, e.g., Edge or IE Mode. Configuring neutral sites ensures that all applications using these authentication servers, both modern and legacy, continue to work. Your administrator should configure the Site List with the appropriate URLs for authentication and SSO services and should explicitly set the <open-in> value to None, as shown in the example below:

In our case, this did not resolve the issue – the page was still displayed the Edge and did not engage IE Mode. We presumed this meant that there was some other redirection happening to a service that did not have an explicit neutral site entry in the Site List.

Normally we might expect a network engineer to solve this problem since it is outside the domain of the Documaker application… but where is the excitement there? We dug further using a network proxy and debugging tool called Fiddler. Fiddler captures the network traffic between the client machine (our computer) and the backend servers and provides exhaustive detail that can be used to determine what’s happening with redirection.

In the screenshot below, we see on line 27 that traffic originates from an iexplore process (Edge opens a separate process to handle IE Mode). On line 28, we see that the traffic originates from an msedge process, which is unexpected.

We know that the addresses shown in the traffic log are part of OAM redirection, and thanks to work we have already performed, we know that the solution is to add these addresses as neutral sites in the Site List. Additionally, we need to specify an attribute that indicates that redirection is allowed. Repeat this process for each URL where there originating process flips between iexplore and msedge. In our case, the final configuration of the Site List looks like this:

The exact entries in your Site List will of course depend on your enterprise architecture. It may be necessary to use multiple entries, especially where load balanced servers or domain name masking schemes are used. Our Fiddler traffic log now shows all authentication traffic using the iexplore process (note that there may be additional traffic shown in the log based on other processes running on your computer; do not add these to your Site List).

For the final validation, we opened Documaker Interactive, noted that SSO functioned as expected, and the pages loaded in IE Mode, as indicated by the Internet Explorer icon shown next to the address bar. Case closed, bring on the next adventure!

Side note

If you need more time to identify your authentication servers, you can configure a policy to keep all in-page navigations in IE mode to allow your users to continue their workflows uninterrupted. To minimize the use of IE mode when unnecessary, disable this setting once you've identified and added your authentication servers to the site list. For more information, see Keep in-page navigation in IE mode.

Special Thanks to Andy Little

Internet Sites Mentioned

https://docs.microsoft.com/en-us/deployedge/edge-learnmore-inpage-nav

https://www.telerik.com/fiddler

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWEHMs

https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/