Updated November 2020 to include reverse proxy to platform cache services and views.
I’m often asked how one can securely expose the Cireson Portal for Service Manager to the Internet. My advice is that it’s no different than exposing any other web application to the Internet and depends on the customer’s network topology and internal security policies.
Here is a working example and reference architecture that can be adjusted to suit your specific environmental needs.
Azure Example
Reference Scenario (Contoso):
Contoso has the Cireson Portal deployed internally using Windows authentication, and they want to expose the Cireson Portal securely over the internet so external users can access Work Items and log tickets with as little additional infrastructure as possible. Contoso requires the least amount of ports possible open between the front-end and back-end zones to lower the attack surface, and virtual machines cannot be domain joined in the DMZ.
High Level Steps for Deployment:
- On the existing Cireson Portal copy the website files from C:\inetpub\CiresonPortal to a new folder called ExternalPortal in C:\inetpub
- Create a new website called ExternalPortal in IIS, point to the newly created folder C:\Inetpub\CiresonPortal, set a random http port binding such as 9110
- Update Platform_Cache.config to include a listener for the http binding port (9110 in this example)
- Enable forms authentication on ExternalPortal
- Deploy a Windows Server workgroup VM in the DMZ and configure a reverse proxy in IIS to look at the backend IP address of the ExternalPortal VM and Port number 9110.
- Have the network team create a firewall rule between the workgroup IIS Server and the backend portal server on the port set in step 1.
- Test and confirm connectivity
Diagram:
Contoso Production Network Components:
- Frontend Subnet (DMZ): 192.168.1.0/24
- Backend Subnet: 192.168.2.0/24
- Workgroup Webserver in DMZ: 192.168.1.4/32
- Cireson Portal: 192.168.2.4
Contoso Azure Resources:
Internet Facing Load Balancer: Front end IP address that publicly resolves from portal.contoso.com, Inbound NAT rule targeting the workgroup IIS server on port 443.
Virtual Network:
Contoso-Vnet01, configured with two subnets, Contoso-Prod-FE & Contoso-Prod-BE with a CIDR of 192.168.1.0/24 & 192.168.2.0/24
Workgroup IIS Webserver:
Windows Server 2016 with IIS, URL Rewrite and reverse proxy configured (more on this configuration latter).
Network Security Group (NSG):
DMZ, controls inbound and outbound network traffic between our frontend and backend zones, is the azure version of a firewall appliance where in this case its denying all traffic and only allow port 9110 to and from the backend. Associated with the frontend subnet 192.168.1.0/24
Configuring a Forms Authentication Portal:
As we want to minimize the infrastructure requirements, an additional portal website for forms authentication will be created on the existing back end server.
Important Note: When creating an additional website this way we must remember to update website files for the ExternalPortal with each future CiresonPortal version update.
- On the existing Cireson Portal copy the webfiles from C:\inetpub\CiresonPortal to a new folder called ExternalPortal in C:\inetpub
- Create a new website called ExternalPortal in IIS, point to the newly created folder C:\Inetpub\CiresonPortal, set a random http port binding such as 9110, do not start website and click OK. Make sure which port you choose is allowed outbound and inbound on the windows firewall of the portal server.
- On Application Pools – Right Click ‘ExternalPortal’, and go to ‘Advanced Settings’, change Identity to a Windows Service User
- On ExternalPortal – double click authentication, disable windows authentication and enable forms authentication.
- Start the website, and confirm website loads from the portal server.
Configure platform Cache listener
With the introduction of the Platform Cache service for a number of different views and processes in the portal we need to make sure this windows service on the backend is also listening on the same port as our Portal website so platform cache traffic can be routed to the service correctly, to do this we need to add a listener for http://*:9110/platform (Or whichever port you have chosen)
- On your portal backend server navigate to C:\inetpub\CiresonPortal\Platform\platform_cache.config (Ensuring to use the CiresonPortal location not the external portal as the windows service is installed to the location mentioned)
- Add the below listener to your urls
Configure the Reverse Proxy:
- Deploy a Windows Server workgroup VM in the DMZ, add the IIS server role and install IIS URL Rewrite & Application Request Routing from the Microsoft Web Platform Installer.
- Create a DNS A record that can publicly resolve the DNS name, for demo purposes I’ve created portal-contoso.cireson.com to point at my azure load balancers front end IP Address of 40.74.234.192
- Open IIS Manager and select the default website, double click URL rewrite, add rules, and select reverse proxy. If prompted to enable Application Request routing, select OK.
- Configure the rule to look at the backend IP address of the ExternalPortal VM and Port number 9110 – don’t use http or https in there.
- Install Certificate that matches your public DNS and Configure SSL binding for the default website:
- Test and confirm connectivity from an internet connected device.
Additional Resources:
- https://www.iis.net/downloads/microsoft/url-rewrite
- https://www.iis.net/downloads/microsoft/application-request-routing
- https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-vnet-plan-design-arm
- https://docs.microsoft.com/en-us/azure/virtual-network/manage-network-security-group
- https://weblogs.asp.net/owscott/creating-a-reverse-proxy-with-url-rewrite-for-iis
- https://community.cireson.com/