Why a Reverse Proxy?
Data and network security is a common issues in environment where CC Agents are outsourced or temporary employed.
Financial organization (Banks, Insurances ) in particular have reasonable concerns when access to business data and internal networks are not protected or hidden. Giving visibility of sub nets and domain names is reason of concern since the worst attacks could initiate from inside.
Basically, a reverse proxies will hide your data center infrastructure from the Agent Network. So it is mainly a case of security by obscurity.
It can also protect applications running in the data center from some kind of DOS (distributed denial of service), especially if the application is "heavy", acting then as a caching layer. In conjunction with load-balancer acting as front end and protected both side by a firewall, it could really make the data center hard to attack from inside.
Be aware that it will make consume more server power, and add a layer of things that can break. Remember that a reverse proxy will have to handle more connections (usually two times more: connections to browsers and connections to your web server).
Finesse RestAPI
Finesse provides a set of RestAPI and also a sample NotGadget sample that is suitable for deployment across a Reverse Proxy. The NonGadget sample (https://github.com/CiscoDevNet/finesse-sample-code/tree/master/NonGadgetSample) also contains a configuration for a Reverse Proxy, but don't confuse this with the security scope of this post: that Reverse Proxy configuration is only used to address the common issue of the Same Origin Policy Same-origin policy - Wikipedia, the free encyclopedia, and in that case the Reverse Proxy is not in between the browser and the Finesse server, but it is co-hosted with your custom Finesse web app.
Finesse Container OOB
This is what we would like to have running with a Reverse Proxy: the standard out-of-the-box (OOB) Gadget container we all love connecting Finesse server, but going through a Reverse Proxy box.
The Agent will enter https://rpx-finesse-a.hideme.com on 192.168.1.1 which will be transparently remapped to https://inside-finesse-a.private.com on 10.58.16.182, and viceversa during the http(s) traffic.
Now, we need this for Finesse and for all the other Contact Center apps, like CUIC, eGain..., and we also would like to have Finesse container able to render LiveData gadgets as well as other 3rd party Gadget.
The 'unsupported' solution
I could get Finesse OOB container (the standard Finesse), CUIC and eGain for PCCE10.5 working across a Reverse Proxy in both http and https mode.
Complexity is not in mapping front end to back end dns names and ip.
Finesse Gadget Container running as browser has multiple connections to Finesse server (static content, bosh, admin, LiveData, Silent Monitoring).
Complexity consists in modifying the content of the HTTP response traffic in order to make the Agent browser loading JavaScript which is re-mapped to talk to the Reverse Proxy. If you don't do this Finesse Container stops working after the first HTTP interaction because it tries to reach a domain and a sub-net unknown and unreachable.
It was a huge effort and extensive use of (personal) time, all dedicated to reverse engineering of HTTP traffic sniff, as well as research and troubleshooting work.
I tested most of the functionalities, included Finesse cluster fail-over, CUIC reporting, eGain email/chat, and all functionalities seem to work.
Testing was based on Apache 2.4 configured as Reverse Proxy. This was a dedicated Windows Server running Apache. The VM is configured with dual NIC (front end and back end interface).
Although no change was required for Finesse, CUIC and eGain (default installation. no hacking), this setup is not supported by Cisco (no TAC support, no minor or major upgrade support) since it is pure configuration of non Cisco component (the reverse proxy), which could affect the behavior of standard Cisco applications.
For every upgrade a regression test must be run to verify that nothing has changed in terms of Finesse functionalities.
Just to make an example, my exercise was based on Finesse 10.5 which use port 8443 as SSL for the static content, while in release 11 the port is now 8445. Regression testing will be required.
The outcome consists in guidelines and reverse proxy sample configuration.
Customer has to be aware that any issue must be replicated in supported deployment (no reverse proxy. straight connection) in order to claim support.
We assume partners/customer take ownership of the Reverse-proxy configuration.
Partner can include testing as part of the deployment project before deploying in production.
How it works
Below a simple text format of the interactions:
Browser <= Front-end Network => RP <= Back-end Network => Finesse Server (and CUIC, eGain…)
There will be 2 DNS server, one for the front end network and one for the back end network. they will serve for different domain and sub-nets.
All Front-end DNS hostnames (the one defined in the RP, let’s say RP hostnames) start with rpx-<hostname>.hideme.com
All Back-end DNS hostnames (the one on the datacenter) start with rmlab-<hostname>.private.com
Example:
Browser point to rpx-finesse-a/b.hideme.com.
Reverse Proxy elaborate the traffic for rmlab-poc-ccd-a/b.private.com
Notes:
Finesse Back-end connects CUIC through the RP to avoid certificate mismatch if you are on SSL
Finesse layout will refer to LiveData and CUIC Reports permalink using RP hostname and not CUIC backend hostname.
Example, in Finesse Layout.xml you will have:
<gadget>https://rpx-cuic.hideme.com:8444/cuic/gadget/LiveData/LiveDataGadget.jsp?gadgetHeight=310&viewId=99E6C8E210000141000000D80A0006C4&filterId=agent.id=CL%20teamName</gadget>
For this reason, the Back-end DNS have to resolve also CUIC routing using RP name (rpx-cuic.hideme.com) pointing on the back end interface of the Reverse Proxy server.
It is required to manually create SelfSigned certificates for rpx-cuic.hideme.com to be imported into Finesse a/b as tomcat-trust
Further testing on 11.5 will be done once available, including SSO.
If you are interested in the guidelines, pls contact me.
Regards
Marco Pirrone
Contact Center Specialist (CSE)
EMEAR Customer Collaboration Team
Email: mpirrone@cisco.com
