Best Practices

App Gating & Best Practices

App Gating refers to the process of restricting access to certain resources such as SaaS Applications in order to bring the same level of added security from Twingate as can be used for all other (private) resources (such as servers behind ssh, RDP, CI pipelines, web applications, etc.).

A word on Policies

All Resources in Twingate are typically protected behind Resource Policies: those policies do not guarantee access to a resource, but instead protect it by defining necessary conditions for access.

For example, a valid Resource Policy protecting a sensitive Linux server could be to:

  • Require 2 Factor Authentication
  • Require that the device requesting access has hardware encryption
  • Require authentication every hour

Outside of Resource Policies designed to protect both private and public resources, Twingate provides 2 additional types of Policies:

  1. The Admin Console Policy
  2. The Network Sign In Policy

Let's dive a bit deeper into both.

The Admin Console Policy

The Admin Console Policy (or Admin Console Security) only protects a particular kind of resource: the Twingate Admin Panel itself. It is a separate Policy because it applies only to a unique group of Twingate Users: the Administrators.

The Network Sign-In Policy

The Network Sign-In Policy does not protect any resource at all like Resource Policies do: it simply defines how frequently a given Client should re-register itself against Twingate (by asking the user to authenticate their Twingate Client against the Identity Provider, from their Device).

Effectively the Network Sign-In Policy provides no access to any resource since resources are all protected by Resource Policies (and the Admin Console is protected by its own Policy, as mentioned above).

Note: The name of this feature will likely change in the future to better align to what it actually does and to provide more clarity to our customers (our current suggestion internally is to call it "Device Registration Policy" but we are still refining the exact term).

App Gating Best Practices

App Gating SaaS resources via an Identity Provider means controlling access to those resources by using specific Resource Policies: this means that the Identity Provider itself can be considered a Twingate Resource.

Since Twingate also relies on the Identity Provider for user authentication, when dealing with App Gating, the IdP holds a peculiar place because it is considered both a Resource and the Identity Provider.

Depending on how frequent Twingate requires Clients to re-register (as per the “Network Sign-In Policy”), a catch-22 situation can appear: if the Network Sign-In Policy is too short, it is possible that a Client needs to re-register but simply cannot because the sign-in page of the IdP itself is a protected resource that can only be access by a registered Client (restarting the Twingate Client solves the issue but is far from ideal from a usability stand point).

In order to avoid this situation, and since there is no added security benefit from imposing a short Network Sign-In Policy, Twingate highly recommends a default Network Sign-In Policy period set to 31 days and will likely enforce it as a minimum in the future.

With those requirements in place, an App Gating “lock out” can only happen if the following two statements are both true for a given user:

  • The user has not accessed any Resource of any kind for 31 days (accessing a Resource effectively resets the Network Sign-In Policy window)
  • And the user has not restarted their device or the Twingate Client for 31 days

We will continue to refine the specifics of the Network Sign-In Policy in the future and make sure to provide updated best practices for App Gating and other use cases.

📘

TL/DR

When using App Gating, remember to set your Network Sign-In Policy to a minimum of 31 Days in order to avoid a potential lock-out issue.


Did this page help you?