Skip to Content

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:

image

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Ivan Tagiltsev
    Greetings, Rory.

    The approach seems interesting, although you forgot to mention that exposing internal portal to regular internet users, in case it is configured to SSO authentication against LDAP, is impossible. We had this requirement at one of our customer sites, and solution we came up with with was a totally separate portal installation with reverse proxy, with no SSO against LDAP, as any workaround wouldn’t work out.

    With best regards,
    Ivan Tagiltsev

    (0) 

Leave a Reply