You have to deal with the following main topics when integrating web applications into a reverse proxy.
A proxy-aware application is one that emits (HTML) content containing links that either point to the reverse proxy or are not fully qualified URLs. A content provider using proxy-unaware links is not working properly because the link points to a host that is not visible in front of the reverse proxy or the resource is not mapped on the reverse proxy's URL namespace, see also the chapter: Alternative path definitions.
We recommend trying to configure the application to be proxy aware which is often possible by means of proper configuration. Sometimes, it is also worth trying different HTTP host header settings using the
Static host header value parameter within the mapping view, see the figure: Sample mapping view, in the chapter: Mapping.
Never map the root location
/ to an application. Configuring
/ means that you may have settings conflicting with other applications and that you allow unrestricted URL name space access to the application which is a security risk. It's better to configure an URL prefix for applications using
/ by setting the mapping type "subnamespace or pathinfo".
Applications which are not proxy-aware need content rewriting which is either configured within the mapping or by using a dedicated RewriteFilter resource.
In a NEVIS single sign-on environment, user authentication is managed by nevisProxy/nevisAuth. The application delegates the actual authentication process to these services. Regardless of this delegation, all application servers that can be reached through the nevisProxy have to trust the proxy to forward only authenticated requests.
Since an application server no longer authenticates the user directly, it at least have to be able to extract the user's identity from a request. There are many different ways available, to propagate the user's identity to the application. While you may choose individual solutions for each application, we recommend you define a standard on how to do this normally, within your infrastructure in order to narrow the variety of solutions.
You also have to ensure that proper timeout settings have been applied to every application server (the application's timeout shall be higher than the one configured within your realm), and that the application does not allow access by HTTP requests that lack the defined user identity propagation token.
Similarly, make sure to store the application's session cookies within nevisProxy in order to bind the application's session to the user's authentication session of the configured realm, see the chapter: Cookie management.