The Portal offers an alternative way for users to connect to protected network resources. Instead of having to install a Client, the users connect using just a browser via a Client instance hosted on the Portal Appliance.
Under the covers, the Portal utilizes the same approach for trusted connectivity as with all Appgate SDP Clients. Each time a user connects they will be assigned an available Client instance. They then sign-in in the usual way with any Policy assigned to that Client setting the access rights and routing in the usual way. In a typical environment, a Portal would be deployed as a standalone appliance outside the protected network, such as in the Cloud.
The Portal allows up to about 1000 Clients to be hosted (depending on the memory available) - each supporting one user/browser. Each Client instance assigned to an authenticated user will consume one Portal user license.
Use the Appliances UI to configure Portal.
Basic operation
The Portal provides a Client instance for each user rendered in its own tab in the browser. Operation is very similar to the installed Client. The main difference relates to the use of some notifications to assist users with some operations such as navigating between tabs. There is also a banner at the bottom - which in the first instance asks that users enable notifications - which is strongly recommended for the best user experience.
For security reasons, and to preserve isolation between these Client instances, each one is run within its own (Linux) namespace. Clientd manages the availability of these Client instances so that when a new user connects they are allocated a spare namespace. This process is managed based on a combination of memory usage and memory availability so that there are plenty of 'hot' Client instances ready almost immediately.
The user can then sign-in using their allocated Client instance in the same way as they would with the full Client (however some hardware-centric means of signing in such as Certificate are not supported). Each user session is given a unique cookie which ensures all subsequent traffic (of whatever type) sent from that user is directed through their own namespace/tunnel:
Client UI traffic (/client) is handled by webd (NGiNX uses the HTTPS Certificate) and provides: the sign-in page, app shortcuts and limited Client controls; all very familiar to a user of the full Client.
The Portal itself will be using public DNS, so if it tried to resolve the (protected) hosts using the default DNS they would resolve to itself (if you have set DNS up correctly). This will not help the Portal to direct the user's traffic to the protected hosts so once signed-in, dnsproxyd (based on CoreDNS) uses the cookie to direct each user's DNS traffic to their own namespace. The Client's tun driver routes this traffic via the appropriate secure tunnels to the DNS servers behind the Gateways in the usual way. The Client therefore should have the usual DNS Policy/Entitlement (used by the full Client) which ensures these internal DNS server(s) can be accessed.
NOTE
The Portal will require that a default DNS server is specified in the user's DNS Policy. Otherwise the DNS Server in the IdP will be used which is assumed to be the default.
App traffic (from its own tab in the browser) is reverse proxied directly by the NGiNX instance in the Portal (NGiNX uses the Proxied Entitlement Certificates) and uses the cookie to ensure traffic is directed through the user's own namespace. The Client's tun driver routes the traffic via the appropriate secure tunnels to the (protected) hosts behind the Gateways in the usual way.
Using a cookie in this way has some security implications but these are offset by the operational advantages it brings. From a security perspective, the fully random cookies are voided when the user signs out or five minutes after the last tab is closed. The benefit is that there is no requirement to configure any specific Entitlements for use with the Portal as it has been made to operate in almost exactly the same way as the full Client. The only changes you might need to make are to:
the IdP due to some slight differences in the way mfa at sign-in and SAML works;
the Policy where you may want to limit the number of Entitlements that can be accessed via the Portal.
the Policy assignment criteria where some claims may not be available from the Portal (such as the device firewall status); and others are required to uniquely identify Portal users (such as profileName or identityProviderId).
DNS requirements
The Portal requires a FQDN for the Portal Hostname where users go to sign-in using a web-Client. They will also be redirected here if they use the URL of the protected host they are trying to access. A PKCS#12 file containing a certificate signed by a trusted CA (for the Portal hostname) and the private key; these are required to terminate this HTTPS connection from the user.
The Portal does not perform any URL re-writing; instead the Portal uses a reverse web-proxy (based on NGiNX) which terminates the user's app traffic and then forwards it on to the protected hosts (via Appgate SDP Gateways). With no re-writing, the app hostnames used in the Entitlements (to forward the traffic to the protected host) must be exactly the same as those used to connect to the Portal in the first place. It is therefore a requirement that the app hostnames entered into the browser (or configured in app shortcuts) resolve to the Portal's own IP address. Effectively this requires that the internal hostnames (but not internal IP addresses) of the protected hosts are published externally. All protected hosts accessed through the Portal therefore require an external DNS entry which must include a CNAME to the Portal - clearly this is only possible for resources which you have control over.
The Portal operates as a reverse proxy when handling user traffic. This means that it must terminate any HTTPS connections, decrypt and then re-establish an onward HTTPS connection to the protected hosts. The Portal supports the use of multiple PKCS#12 files containing a certificate signed by a trusted CA (for the protected host) and the private key. An alternative to using multiple certs is a wild-card cert - but this should be limited in scope because of the security implications in the event of its loss.
Deploying the portal
These steps should be followed when deploying the Portal. If this order is not followed then the DNS changes required at the end are very likely to disrupt existing user access.
Ensure the internal DNS names used for the (protected) hosts are suitable for publishing to external DNS. If they are not, then create a new alias for the (protected) host and add this alias as a CNAME to its internal DNS record.
Deploy Appgate SDP and ensure users of the full Client get the required access to the (protected) hosts.
Add a Portal appliance to the Collective and locate this outside of the network perimeter close to where the majority of users are located.
Configure HTTPS Settings; the Portal Hostname will require a HTTPS Certificate (PKCS #12).
Add the required external DNS record for the Portal hostname.
Decide on the IdP you are going to use - you may want to create a new one:
The MFA at sign-in feature works slightly differently for Portal users, so you might want to use a different IdP.
If SAML authentication is being used, a new (or updated) SAML IdP configuration will be required with a different Single Sign-on URL (ACS URL).
Decide which Client Profile you are going to use - you may want to create a new one because:
you might be using a new IdP.
the profileName claim might prove useful when assigning Policies for Portal users.
Select the chosen Client Profile in User Access Settings.
Configure a Policy for Portal users and ensure you can sign-in using the Portal (and that the required app shortcuts appear). It is suggested that you use the clientType "web" and/or the ProfileName (see 7) to assign the Policy.
Create the Proxied Entitlement Certificates (PKCS #12) and upload it to User Access Settings. This could be a wild-card cert, multiple individual certs or a single cert with a number of SAN entries which covers all the (protected) hosts you want to access through the Portal.
Add any specific ports you need (if using something other than 443).
Add the (protected) host's DNS name as a new CNAME to the Portal's external DNS record.
Customize the sign-in page to suit.
Check the System security - best practice guide in respect of Portal usage.
If you have any problems with user access at this point, there are some Portal troubleshooting commands available.
Limitations
The Portal function in v6.0 has some limitation in the operational capability provided at this time - which will be enhanced in future versions.
Due to the security restrictions within modern web browsers, Portal cannot support applications that use cross-origin requests. For example, a web app hosted on https://app.company.com that uses https://api.company.com as rest backend, is considered as cross-origin request; so is not supported. All the resources within a web app needs to be hosted on the same domain. (Existing multi-domain web applications can be converted to single-domain web application using a reverse-proxy such as NGiNX - contact support for more information.)
Most SaaS instances will not be able to be accessed via the Portal - as you do not have control over their DNS entries to redirect the URL to the portal.
The Portal requires a WebSocket connection for both maintaining ongoing activity and delivering user notifications. To facilitate that, Portal integrates a single JavaScript file, named "clientless-8c0fff68d47c43fa90127442303db814.js," into the webpages. This file initiates a WebSocket connection to the endpoint "/banner-16872eb861894a7e9e787f6355e95d3b."
In specific instances, this injected JavaScript may conflict with Content Security Policy (CSP) headers, or the rendering of notifications may clash with existing page elements. In such cases, contact AppGate support for resolution.
The Portal appliance does not support any form of integrated HA operation, but multiple Portals can sit behind an appropriate load-balancer.
Only one Portal appliance can be deployed (for a given (protected) host) as the DNS entry has to redirect to just one Portal appliance.
There is limited integrated denial of service protection, so the use of appropriate external protection is recommended.
The (internal) hostname of the application must be suitable for publishing via external DNS (unless using Client side host files).
Only HTTPS applications are supported (RDP over HTTPS is supported).
Web applications must support http/1.1. (AppGate ZTNA uses proxy_pass which does not support http/2.)
Web applications with NTLM authentication are not supported.
A Portal appliance can only support a maximum of 1000 users.
The session will only persist for five minutes after the last connection is dropped.