Appgate SDP protects your environments with multi-stage authentication and authorization that can be configured on an as-needed basis. Appgate SDP offers true multi-stage authorization and complements this with a richer set of authentication options that can be deployed at different points in the usage cycle. This approach changes the traditional view of authentication from being a fixed step in a process. Instead, context is considered, such as what has the user already done and what are they going to do next. The user may have already used multi-factor authentication (MFA) when they on-boarded their device, mitigating the need to use it again.
This section provides an overview of multi-stage authorization security controls that are available from pre-authentication to authorization at time-of-use.
1. Single Packet Authorization - access to Appliances (trusted connection)
Single Packet Authentication (SPA) keys are generated automatically by the Controller and used throughout the Collective for peer-to-peer connections. Separately, keys for Client-to-Gateway SPA access are generated by the Controller uniquely for each Gateway and are included in Entitlement tokens. These parts of the SPA process are completely internal and requires no admin or user interactions.
SPA keys are required for a Client to connect to the Controller. One or more Client profiles are created for the Collective. These profiles include the SPA key and can be distributed as a special profile link, as a QR code, in an email template, or embedded into an on-boarding web page. Multi-tenant environments are supported by multiple profiles generated for the Client, so each tenant has their own key. Only the keys relating to the Client profiles listed in the admin UI will be tied by the Controllers when a Client connects.
2. Device Registration (trusted device)
The registration of new devices prevents one of the most common forms of breach: when stolen credentials are used to sign in to a system from a new device. A cookie is created at sign in and saved by the Controller and the Client to present at subsequent connection attempts. This allows the Controller to perform additional checks at sign in using this information. In the first attempt, the device count is checked and access will not be allowed if the set limit been exceeded. If this check passes, you can require that users perform MFA at sign-in; either to register a new device (once), or for new and registered devices (always).
3. Gather Claims and authenticate (trusted user)
When a user signs in using the Client, it passes up to four Claims (key-value pairs) to the Controller for authentication:
DeviceID
IdentityProvider
Username (not required for SAML)
Password (not required for SAML)
The credentials will first be checked against the system’s blocklist, and then against a defined Identity Provider. If the user is authenticated, the next step is to establish their rights.
4. Policy assignment criteria - authorization (trust through context)
When the user has been authenticated, the Controller uses the Claims information to parse the Policy assignment criteria in all Policies and then assign Policies that are valid for the user.
The Controller creates a Claims Token and Entitlement Tokens listing all valid . One Entitlement Token will be created for each Site identified in the Entitlements. These are sent to the Client which in turn forwards them to the Gateways. If the user’s claims do not match any assignment criteria in any Policies, the user will not receive any Entitlements.
The lifetime of a token can be set so the user will be re-authorized every x minutes. Tokens can also be renewed when required by the administrator. For more details of the token flow, see the System operation section.
5. Conditions, claims & user interactions (elevating trust level)
Checking claims using Conditions
On receipt of the Claims Token and Entitlement Token, the Gateway translates Entitlement actions into firewall rules, authorizing traffic from that Client depending on whether Conditions are True or False.
The Entitlement token is provided to the Client by the Controller based on Policy assignment criteria. Included in each token is the list of Gateways for that Site. The Client selects and connects to a Gateway, then forwards the token to establish firewall rules.
When the token is about to expire, the Gateway will automatically notify the Client. The Client then asks the Controller for a new token. The Entitlement token will be renewed new and will contain the most up-to-date Entitlement and Condition information.
Every Entitlement can be linked to a Condition which is checked at time of use. If no alternative Conditions have been included in the Entitlement, then the default status is for the Entitlement to be always available. A Condition can include a user interaction that is triggered if other access criteria are false. Where the user interaction requires a response from the user before access will be allowed, the connection to the target host remains invisible until a response has been provided that the Condition passes.
The claims are regularly re-evaluated and firewall rules re-configured in response to any real-time changes.
Performing user interactions
User interactions allow the user to gain access to an Entitlement that is currently blocked due to Conditions. User interactions satisfy alternative access criteria such as performing MFA (multi-factor authentication).
When an Entitlement is blocked and a user interaction has been configured within the Condition, the Gateway will send a user interaction to the Client. If the Client determines the user's response is appropriate, the Controller will update the claims token, and the Gateway will re-evaluate the Conditions in the Entitlement to produce new firewall rules.
The types of user interactions available are:
Display Message. Provides the user with information, such as 'please use the wired network for access'.
Require MFA. Perform MFA for access.
Provide Reason. Enter text before continuing.
Password. Enter or re-enter their password.
For more information, refer to the user interactions section.