Profound UI can be used to allow users outside of the local network access to applications. This can be very secure, however the default configuration provided by the Profound UI installer is appropriate for a development environment only, and should NOT be used for an HTTP server that is made accessible outside of the local network.
Recommended Approach for External Access
It's recommended to use a separate installation of Profound UI and HTTP server instance that are dedicated to external use (separate from installations used for internal purposes). You should work through the configuration and security checklist below before making the HTTP server available to the outside network.
If you have not installed Profound UI on the server before, you can start by running Profound UI and using the default settings. If you have already installed Profound UI on the server for other purposes, you should start by installing a separate copy of Profound UI. This is done by giving a unique product installation library name, HTTP server instance name, and HTTP server port during installation.
Configuration / Security Checklist
After you have installed a copy of Profound UI that is dedicated to external use, the following checklist can be used to configure and secure the installation.
This step is optional, but provides another layer of security and may be required by your organization's security policy.
Profound UI runs natively on IBM i and can only be served using the IBM HTTP Server on a system running IBM i. Many applications that are deployed to the Internet use a "multi-tiered" model, where the public-facing HTTP server and the database reside on physically separate machines (hosts). These types of applications are deployed such that only the HTTP server host is accessible over the Internet. The firewall is configured to permit connections from the Internet to the HTTP server host, but not to the database host. Connections to the database host are only permitted from the HTTP server host.
This type of deployment provides another layer of protection in many ways. For example, attacker who is able to gain partial or full control over the HTTP server system by exploiting a flaw in HTTP server software or configuration, the damage is more limited as this does not necessarily give the attacker access to the application's data. Some organizations may actually require this type of deployment for any applications that are deployed to the Internet, using this reasoning.
Profound UI can be deployed to the Internet in this way by setting up a separate physical server (any operating system), running any desired HTTP server software (i.e. Apache, IIS, etc.), and configuring this HTTP server to function as a reverse proxy. A reverse proxy will recognize certain URLs requested by the end user's browser as being located on a remote server (the Profound UI HTTP server on IBM i, in our case) and will fetch the content from the remote server and return it to the end user's web browser. The end user's browser communicates only with the reverse proxy, so there is no need to permit outside connections to the IBM i server.
A reverse proxy can be configured for Profound UI by mapping URL paths starting with '/profoundui' and '/ext-22.214.171.124'. For example, this can be done in Apache using the following configuration:
ProxyPass /profoundui http://IBMi/profoundui
ProxyPassReverse /profoundui http://IBMi/profoundui
# Required for Fusion Charts use
ProxyPass /FusionChartsXT http://IBMi/FusionChartsXT
ProxyPassReverse /FusionChartsXT http://IBMi/FusionChartsXT
# Required for mobile scroller layout
ProxyPass /iscroll http://IBMi/iscroll
ProxyPassReverse /iscroll http://IBMi/iscroll
# Required only for Atrium
ProxyPass /ext-126.96.36.199 http://IBMi/ext-188.8.131.52
ProxyPassReverse /ext-184.108.40.206 http://IBMi/ext-220.127.116.11
If using a reverse proxy, HTTPS must be implemented at the reverse proxy. The firewall should then be configured to permit traffic to the reverse proxy host only.
(2) Configure VPN (optional)
HTTP communication is done in plain text, so all details of all transactions are visible to anyone who can monitor a network link between your server and the end user. This includes user names and passwords, as well as the information your applications are dealing with. For this reason, Profound UI should never be deployed outside of the public network without some form of encryption to protect against data being intercepted between the client and server. Using VPN is not required, but if desired, it can be used to provide encryption of data transmitted over the network between the client and server. VPN also provides another layer of authentication, the user must have some form of credentials to connect to the VPN.
VPN is implemented at the TCP/IP network layer, and so is transparent to Profound UI. The only consideration for Profound UI is that your organization’s VPN configuration will need to be updated if it imposes restrictions on what hosts and/or services/ports VPN users can access on the private network the IBM i server is connected to. The IP addresses and port that will be used for the external Profound UI HTTP server are configured in section Configure IP Addresses and Ports.
If not using VPN, then it is required to configure SSL/HTTPS as described in the section Configure SSL/HTTPS.
(3) Configure DNS
Configure your DNS with a host name (A) record. The IP address of the host name should be set to the appropriate public IP address belonging to your organization. The host name must be at least chosen, if not actually created, before configuring SSL as the host/domain name is required in order to create an SSL certificate.
(4) Configure SSL/HTTPS (optional, but required if not using VPN)
If using reverse proxy, HTTPS must be configured at the reverse proxy and is not required for the Profound UI HTTP server on IBM i.
HTTPS provides protection of all HTTP data transmitted over the network between the client and server using public key encryption. If not using VPN, it’s required to setup HTTPS for the external Profound UI HTTP server. This protects not only the data that the applications are dealing with, but also the credentials that users enter to sign into the applications.
HTTPS is implemented using SSL at the TCP/IP network layer and so is transparent to Profound UI. SSL requires installing a certificate on the server. The certificate contains the server’s public encryption key and also confirms the identity of the server to any clients. SSL certificates are managed using IBM i’s Digital Certificate Manager (DCM). The DCM associates SSL certificates with an ‘application identifier’ that then used by applications to reference the certificate. Once configuration in the DCM is complete, the external Profound UI HTTP server can be updated to turn on HTTPS.
See here for detailed instructions on how to install a certificate in the DCM and configure the HTTP server for HTTPS:
The IP address (network interface) and ports that the HTTP server will listen on are specified by the Listen directive. The format of the Listen directive is:
If no IP address is specified, the HTTP server will listen to the given port on all network interfaces. Multiple Listen directives can be used to listen on multiple IP addresses and ports.
For example, the Listen directive in Profound UI’s default configuration looks like this:
This listens on port 8080 on all IP addresses.
For external use, it’s recommended to use port 80 (if using HTTP) or port 443 (if using HTTPS), as these are the default ports. When using a non-default port, the user must enter a port number in the URL. When using the default port, the user can omit the port number from the URL and the browser will determine what port to use based on the protocol specified in the URL.
For example, to listen on port 443 on IP address 10.0.0.1 only, using the following directive:
(6) Configure Access to Profound UI Components
The HTTP server configuration provided by Profound UI allows all components of the product suite to be accessible. This includes development and administrative tools that are not usually appropriate for users outside of the private network.
Profound UI programs are named using a numbering system which groups the programs by product component. This allows individual components to be enabled/disabled in the HTTP server configuration by removing the URL mappings for a product component.
URL mappings are defined by the ScriptAlias and ScriptAliasMatch directives in the HTTP server configuration. The ScriptAlias directive creates a URL mapping for a single program, and the ScriptAliasMatch directive uses a regular expression to select multiple programs.
Profound UI programs that are designed to run under the HTTP server are named like this:
Where ‘XX’ is a series number that indicates the product component, and ‘YY’ is the number of the program within the series. The product components are grouped into the following series of programs:
Any ScriptAlias or ScriptAliasMatch directives referring to development or administrative tools (shown in red above) should be removed or adjusted to prevent access. If you don't want to completely remove a component but want to modify user access to the program, you can see an example of how to go about this here.
Keep in mind that a Genie session is equivalent to a 5250 terminal emulation session. Unless it’s desired to give external users all capabilities they would have in a 5250 terminal emulator (i.e. command line access, etc.), access to Genie should be removed as well.
(7) Configure Authentication Type
Profound UI supports various forms of authentication. The HTTP server configuration must be adjusted from the default if using an authentication form other than IBM i system user profile / password.
Detailed instructions on HTTP server configuration for authentication here:
If it’s not desired to give each end user an IBM i user profile, using a validation list might be a good option. A validation list is an IBM i object that has the sole purpose of storing a list of user names and encrypted passwords. Validation lists can be used with the HTTP server as an alternative to setting up IBM i profiles for web users:
The HTTP server has imposes a limit on the number of CGI jobs that will be created for each instance. A ‘CGI job’ is a job that the HTTP server uses for running a custom program to produce web content. Since Profound UI programs use CGI, the limitation on CGI jobs is effectively the limit on the number of sessions that can be run.
The default configuration provided by Profound UI limits to 1000 sessions. To change this, adjust the following directives:
MaxPersistentCGIJobs : Set to the maximum number of sessions that this HTTP server instance should support. This refers to a specific type of CGI job that Profound UI uses to maintain user session state.
MaxCGIJobs : Set this to the number specified above multiplied by 1.2. For example, if MaxPersistentCGIJobs is 10000, set MaxCGIJobs to 12000. This allows for some extra shared jobs not tied to a particular user session that are used by Profound UI to run various utility programs.
(10) Configure Profound UI Entry Points
The process here depends on what Profound UI components are being used:
Genie: Equivalent to 5250 terminal emulation, so there is nothing to do here. The entry point will be the initial program or menu specified on the user profile.
Rich Display File applications: These can be launched outside of a Genie session, and can be run anonymously (no sign on), using the authentication form configured in the HTTP server. A session starts with a call to one of your programs. Only programs that you have configured as session entry points will be allowed for this purpose.
Configure entry points for each type of session using instructions here:
Make sure that the session entry point databases do not include any entries for programs that you don’t intend for web users to call directly.
Note that the Profound UI installer will configure entry points that allow sample programs to run, so there will be some clean up to do here even if starting from a fresh/clean installation.
Atrium: The Atrium database serves as an additional set of session entry points for Rich Display File applications. Any menu items with action type set to Rich Display File Program will allow any user with permission to the menu item to run the program. Atrium enforces security by validating the signed in user against the menu permissions. Atrium menu items can also be configured to launch Genie sessions. Atrium does not provide any additional security for Genie, only presentation of the menu. When using Genie, users will have the same access as in a standard 5250 emulation session.
Universal Display File applications: Configure URL mappings for any Universal Display File applications the web users should be able to access through the Web Connector, as documented here:
After all other setup is complete and tested, the firewall must be configured to allow external connections using the port the HTTP server is listening on. If using a reverse proxy, connections should be permitted to the reverse proxy only. Otherwise, connections should be permitted to the IBM i. When this is done, external users should be able to connect to Profound UI to run your applications.