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:

• The Admin Console Policy
• The Minimum Authentication Requirements

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 Minimum Authentication Requirements

The Minimum Authentication Requirements do 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 Minimum Authentication Requirements provide 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).

Additionally, devices must meet either one of the Trusted Profiles or minimum OS requirements detailed on the Device Security page to be able to access Twingate.

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 “Minimum Authentication Requirements”), a catch-22 situation can appear: if the Minimum Authentication Requirements 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).

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 Minimum Authentication Requirements authentication 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 Minimum Authentication Requirements in the future and make sure to provide updated best practices for App Gating and other use cases.