When using a website or web application combined with INETAPP it's recommended to only let the user log-in once. The solution for this scenario depends on your server infrastructure and selected authentication method.
In this configuration, INETAPP would be running in an application server that presents your web front-end or web application as well. It's recommended to set the authentication method to 'Internal web server' for that use case. This enables INETAPP to share the session and authentication with your web application.
Pro | Contra |
---|---|
Easy and seamless integration with web applications | Requires an application server |
If you require another authentication method or INETAPP runs in a separate process (e.g. IIS or Apache with PHP), make sure that INETAPP is accessed by the same host name as your front-end server. Furthermore, the credential store has to be the same for the web application and INETAPP. This is required to enable the client browser to automatically resend the authentication when switching between the web application and INETAPP. The user won't be notified about this re-login so the user experience is seamless.
Pro | Contra |
---|---|
Works with almost any web server | Requires basic or NTLM authentication |
Both server applications must have the same credentials base |
In case you want to install INETAPP on a firewall-protected back-end server, a different setup for authentication has to be used. Since your web site or application is hosted on another (front-end) server, INETAPP has to contact this server to share the authentication. Make sure, this connection is not blocked by the firewall as well.
To set up this solution please:
How it works in production:
It's important in this scenario, that request 1. and 2. pass all cookies (session ID) and header (authentication header). This allows the Login Script on the front-end server to identify a user by session cookie or by authentication.
Pro | Contra |
---|---|
Allows Firewall protection for the back-end server | Additional load on the front-end server |
Single entry point (host) for users | May require a custom proxy implementation |
In this scenario the web site/application server and the server hosting INETAPP are both connected to the same network or the internet. The user can directly access both servers. So in contrast to the front-end / back-end architecture, there is no proxy which can pass the authentication or session data from the web site/application server to the reporting server. So passing the session cookie has to be done by the web site running in the browser of the client/user. For that reason, a front-end / back-end solution is recommended in most cases.
To set up this solution please:
How it works in production:
As you can see, the most critical point here is to pass the session from your web application to the reporting IFRAME. Most browsers will try to prevent you from re-using a cookie for another host. So it requires sophisticated JavaScript knowledge to implement such solution.
Alternatively you may pass the required session data as URL parameters to the IFRAME. But since INETAPP only passes Cookies and HTTP header fields to the Login Script, this would require to extend the reporting server with a plugin to convert the URL parameters to a cookie for authentication.
Pro | Contra |
---|---|
No proxy required | Requires sophisticated JavaScript or Java coding |
No extra load for the web server | Exposes back-end architecture |