In my Accessing Backend Content through the Enterprise Portal from the Internet, 'Accessing Backend Content through the Enterprise Portal from the Internet', I discussed the requirement for the browser to be able to communicate with the backend content server when backend web applications are integrated via the Enterprise Portal. Typically this is an issue in a scenario where users access the portal from outside the company LAN and the content server URL cannot be resolved externally or is blocked by a firewall. The typical approach to resolve this is to make the content server accessible via a reverse proxy which is accessible from the Internet.
But - what about the scenario where you have both internal and external users, accessing the portal from inside the LAN and from outside the LAN respectively? In that case, you might not want to force the internal users to connect to the backend server through a publicly accessible proxy, with the additional overhead that implies.
Another consideration is the protocol to be used to access the backend content. In general, you want to ensure that both the portal and the backend content server are accessed using the same protocol - this is to avoid warnings about secure and insecure content in the browser, or access denied errors in javascript functions due to the protocol mismatch. However, in a typical scenario your internal users might access the portal using HTTP, while your external users access it using HTTPS (perhaps with SSL termination at the reverse proxy in front of the portal). In that case, you will have a protocol mismatch if you force internal users to access the backend content server using a reverse proxy that uses HTTPS - but if you specify HTTP here, you have a protocol mismatch for external users (as well as a security issue since the backend content is served over an unencrypted connection).
In such a scenario you probably want the internal users to connect to the backend server directly, as in the following diagram:
How to achieve this setup? The simplest but most burdensome solution is to make copies of all your roles with backend content, one for internal users and one for external users. Then you point the iViews in the internal roles to system objects which specify the internal name of the backend server, and the iViews in the external roles to system objects which specify the externally-accessible reverse proxy.However, as well as the manual effort required to implement this solution, there is the additional drawback that it doesn't allow for a scenario where a user could access the portal from the LAN one day and from the Internet the next.
An alternative approach is to use different system objects (with different properties for the Web Application Server) for a single iview using Dynamic System Resolution to determine which system should be used for the iview. With dynamic system resolution, an iView can select at runtime from among several systems, based on the location of the current user, group membership or any other logic - however please note that this logic has to be implemented by you. You can refer to the Help topic on DSR for more details.
One final consideration: if you implement a system resolving service for DSR, your service will be passed as arguments the System alias maintained in the iview and the IUser object for the current user. If you want to resolve your system alias depending on some characteristic which cannot be determined from the IUser object, it might be worth considering using the more generic approach of implementing a Customer Parameter Provider for the appintegrator. This allows you to implement your own service to provide dynamically compute values for any parameter used by the appintegrator, including the system. In this case, the portal request object is passed to your service, so you have a different set of information available for deciding the value to return. You can refer to this How To Guide for a sample implementation - the example is for dynamically computing the Locale property, but a solution for the System property would be similar. The customer exit of the Application Integrator also offers a really nice tutorial on using the Customer Parameter Provider, and the author even mentions the use case we are concerned with here, of switching the value of the System property dynamically.
2 Comments
