IFS Applications should never be exposed directly to the internet.
However,
it is possible to forward calls through a proxy such as IFS TouchApps Server or
a similar generic 3pp reverse proxy with filtering capabilities (e.g. Netscaler,
IIS, Apache, NginX). Caution should always be taken when making sensitive
systems accessible from the Internet. Depending on which functionality need to
be accessed from the Internet, only the required requests should be forwarded to
the backend servers. Some functionality should never be accessible from the
internet, such as the Middleware Server Admin Console and all endpoints secured
only by HTTP Basic authentication. IFS consider well known and maintained
proxies safe. The forward filtering and black/white listed IP addresses are
considered a reliable restriction. The Admin Console and HTTP Basic
authenticated integrations may therefore be forwarded to using a proxy if
explicit source IP addresses are white listed and all other access is blocked.
Below is a list of the most common (not all) endpoints to which requests can be forwarded to. See section Browse for all endpoints to get your systems available endpoints. Note that some end-points require IP filtering on the specific endpoint.
Only the endpoints in the list below are hardened. It is necessary to block all other endpoints in the proxy that exposes the IFS Applications to the Internet. All endpoints other than those in the list below should NOT be made accessible from the Internet without whitelisting or using VPN.
The Middleware Server Admin Server URL should never be made accessible from the Internet without whitelisting or using VPN, hence a split of Landing Pages into an "End user" and an "Admin" Landing page so end users will not get broken links in their landing page for the more administrative landing page links
Integration endpoints and
Access Providers using compatibility (HTTP Basic) authentication should also
always be protected by IP whitelisting or by using VPN.
There are several reasons why IFS made the choice to move to a more
secure redirection-based challenge-response authentication mechanism using the
OpenID Connect standard, for example to be able to support multi-factor
authentication, conditional access policies and the b2b collaboration feature in
Azure AD. Since Azure AD support all of this often required functionality, it
was the primary target platform but ADFS was equally important to be able to
support purely on-premise installations or where the customer does not use Azure
AD. Database authentication, where users authenticate using Oracle Database
accounts, was implemented to provide backwards compatibility for existing
customers and to provisioning of development- and test installations. However,
database authentication does not support any of the security features mentioned
above.
IFS Middleware Server has one single point of
entry, the system url. This url holds a certificate and clients that trust this
certificate may use this system url. If any central part of IFS Middleware
Server needs to be accessible from a proxy url on the Internet, all requests
need to go through this single point of access. The proxy url can still be
limited by whitelisting to only forward request that originates from within the
company intranet.
This mean that if Azure AD or ADFS
cannot be used for some reason and instead database authentication is required
and needs to be accessible from the Internet, then the system url must be on a
FQDN that is accessible from the Internet.
Endpoints that can be exposed to the Internet are non-sensitive resources and resources protected by OAuth 2 and OpenID Connect. These include the DEFAULT, B2B and ADMINISTRATION application types, the IFS Database Identity Provider, the IFS Enterprise Explorer Clickonce download and the landing page.
The IEE client in DEFAULT Application Type consists of the following endpoints (OAuth2) :
The Aurena client in DEFAULT Application Type consists of the following endpoint (OAuth2) :
The B2B Application Type consists of the following endpoint (OAuth2) :
The IFS Admin IEE ADMINISTRATION Application type consists of the following endpoints (OAuth2 - IFS identity provider only) :
The IFS Database Identity Provider consists of the following endpoint - which is used if IFS database identity provider is used:
The IFS Enterprise Explorer Clickonce download is located at (No authentication):
The Landing pages and general IEE need access to these url's (No authentication):
PLSQL Access Provider access is always mandatory from the DB - (Basic Authentication)):
Note - requires whitelisting in proxy
Integration end points (Basic Authentication):
Note - requires
whitelisting in proxy
Old access provider end points (Basic Authentication):
Note - requires whitelisting in proxy
Other 3pp endpoints used by IFS Applications (No Authentication)
Note - requires whitelisting in proxy
Internal Administration tools -only available on a separate a port (Basic
Authentication)
Note: These are normally run from the
Application Server itself - must be whitelisted in proxy if forwarded.
If accessing these url's from
Application Server add the external proxy hostname as an alias to the application server
IP in the hosts file.
The TouchApp Server (TAS) is a proxy in it self and often installed on a
separate server, but it can be configured to be accessed from the same reverse
proxy as IFS Applications, but with a separate unique FQDN, port and certificate.
End user end points, publicly available
Admin end points, only accessable locally or whitelisted
The list above is the most common end-points. The technical platfrom allows componects to add their own endpoints even between core releases. To find a list of end-points that is availabe for a specific customer installation the OHS configuration needs to be scanned manually. In the folder ifs_home\wls_domain\instance\config\fmwconfig\components\OHS\HttpServer1\moduleconf there is a number of *.conf files from each installed component that need to expose an endpoint. In this folder search all files for the string 'Location' this will list all end-points that are available for access in IFS Applications.
If IFS Touch Apps are used
in an environment utilizing the IFS Database Identity Provider for the
DEFAULT
Application Type, the IFS Database Identity Provider must be accessible from the
Internet for user authentication purposes, i.e. the system url fqdn needs to be
accessible from the Internet and from the intranet. If all the
DEFAULT
Application Type users (Aurena/IEE/TAS) proxies through the external proxy it
doesn't mean that the proxy need to expose all endpoints to the Internet,
whitelisting internal requests only should be used for all endpoints that should
not be accessible from the Internet. In this case only the
/openid-connect-provider/ endpoint should be allowed to receive requests from
general Internet IP addresses. If Internal clients are not allowed to use the
external proxy for some reason, it is possible to use the same
fqdn on the middleware server so that it can use the same certificate as the
proxy fqdn. This requires an intranet DNS name resolution of the proxy
fqdn to be resolved as the middleware server's intranet IP.
If IFS B2B are used in an environment utilizing the IFS Database Identity Provider for the B2B Application Type, the IFS Database Identity Provider must be accessible from the Internet for user authentication purposes. If also the Application Type DEFAULT is using the IFS Database Identity Provider, the system url fqdn needs to be accessible from the internet and from the intranet. If all the DEFAULT Application Type users (Aurena/IEE/TAS) proxies through the external proxy it doesn't mean that the proxy need to expose all endpoint to internet as a whole, whitelisting internal requests only should be used for all endpoints that should not be accessible from internet. In this case only the /openid-connect-provider/ and /b2b/ifsapplications/ endpoints should be allowed to receive requests from general internet IP addresses. Preferably /openid-connect-provider/ and /b2b/ifsapplications/ should be whitelisted to specific partner IP's as well. If Internal clients are not allowed to use the external proxy for some reason, it is possible to use the same fqdn on the middleware server so that it can use the same certificate as the proxy fqdn. This requires an intranet DNS name resolution of the proxy fqdn to be resolved as the middleware server's IP.