Using the Archibus Smart Client Program with a Reverse Proxy Server
System administrators often establish a reverse proxy to provide Internet users with access to a server that is behind a firewall. Reverse proxies can also balance load among several back-end servers, or provide caching for a slower back-end server. In addition, reverse proxies can simply bring several servers into the same URL space.
The reverse proxy server serves acts as a gateway, which means that all requests must go through the gateway. Typically, the gateway separates a public network from a private network.
Configuration 1: Reverse proxy without authentication
In this configuration, the reverse proxy server simply passes requests to the content servers (e.g. an application server running Web Central). It is responsibility of the content servers to authenticate the user.
The system administrator configures the Web Central server with a non-SSO configuration. When it connects to the Web Central server, the Smart Client detects this Web Central configuration and issues requests for this non-SSO configuration.
Configuration 2: Reverse proxy with authentication
In this configuration, the reverse proxy server is configured to work with an SSO server.
The SSO server could be configured to use standard (security certificate) or custom (form-based) authentication.
Configuring Web Central
The system administrator configures the Web Central server to use one of the Web Central SSO configurations per Configuring the SSO Authentication.
You configure the reverse proxy server to pass all requests from the browser to the SSO server, which forwards them to the Web Central server. To Web Central, this configuration appears just like an ordinary SSO configuration; the Web Central application is unaware of the existence of the reverse proxy server. From the point of view of Web Central, the reverse proxy acts like a typical SSO server: it inserts HTTP headers with SSO information, e.g. “username”.
Authenticating the Smart Client
The Smart Client should not be used in the standard Web Central SSO mode in this configuration, since the computer it is running on is not a part of the private network, and therefore cannot be trusted.
There are two possible configurations for SmartClient in this case:
Configuration 2.1: Certificate Authentication. You configure the proxy server (in essence the SSO server) to request security certificate for all requests from the Smart Client. In response, the Smart Client sends that certificate.
You need to configure the certificate both on the client computer and in the Smart Client. See Configuring Smart Client for Windows Authentication.
This configuration is preferred at high-security sites, such as banking, military and intelligence installations.
When presented with that security certificate, the proxy server passes it to the SSO server. If the security certificate is accepted, the proxy server forwards the request to Web Central. If there is any transformation required for the credentials -- such as translating a user name into an employee ID within the request header -- the proxy server performs that transformation before forwarding the request to Web Central. (In other words, in this configuration, the proxy server acts as the SSO server in providing the user name with which Web Central should process the request.)
Configuration 2.2: Web Central Authentication. The system admin establishes a separate instance of Web Central configured to use non-SSO mode. The gateway is configured to route all SmartClient requests directly to this instance of WebCentral, bypassing the SSO server. Users will log into Web Central, which will authenticate the user. That means that there will be two instances of WebCentral: one in SSO mode, serving browser requests; another in non-SSO mode, serving Smart Client requests.
Other Considerations
SAML-based Reverse Proxy. If the reverse proxy is SAML-based, the gateway can inject the correct header for the requests.
Authenticating Non-Domain Users. Some sites are concerned with authenticating non-domain users on the network. These can be contractors or employees that log in via VPN. Alternately, they may be visitors with physical access to a network connection behind the firewall. Or they may be users using sophisticated techniques to attempt to falsify their authentication information. One solution is to secure the Web Central server beneath an authentication server using certificate authentication.