There are a number of mechanisms in Appgate SDP to help Disable, change or remove access. These can be enforced by Policy, Entitlement, user or device. REST API calls can be made to the Controller to quickly enact any changes triggered by external events.
These mechanisms all benefit from the Token based architecture used throughout the system. This means that it is possible to propagate changes immediately - and not have to wait until the user next signs in/out.
Policies and
Use the Policies UI to configure Policies.
Use the Entitlements UI to configure Entitlements.
Enabling or disabling Policies and Entitlements
Each Policy or Entitlement can have its status set to enabled or disabled. All disabled items can easily be found using the search option status: disabled.
A Policy can be created to provision rights for a temporary purpose, such as for an annual audit, or a short term project. Rather than deleting the Policy at the end of the task and then possibly having to re-create it (when the next audit occurs), use the action button on the Policy form to enable or disable it when required.
An Entitlement may have been created to provision access to a new resource or online service. Administrators can prepare in advance for launch of the new service and only 'switch it on' when all the preparation has been completed by using the action button on the Entitlement form. There is no need to edit the Policies.
It is also possible to prevent Policies being used by deleting all assignment criteria and Entitlements by choosing Conditional access control without adding any conditions.
Configuring Policies and Entitlements to prevent access
Preventing specific users getting access (to increasingly specific hosts):
Configure a Stop Policy and set Policy assignment criteria username is <name>. This will prevent the user accessing any hosts.
Edit the Policy assignment criteria and set username is not <name>. This will prevent the user accessing all the hosts specified in the Entitlements (in this Policy).
Restricting the Entitlement using a Condition:
Set a Condition with all below are true and
specify that the array groups has a matching item <finance>.
add username is not <name>.
Edit the Entitlement - instead of <Always Allow Action(s), select the new Condition using <Condition Based Access>.
This will prevent the user accessing all the hosts in that specific Entitlement. (No change is required to the Policies that include this Entitlement.)
Set a <Block> host Action within a new Entitlement, create a new Policy containing that Entitlement and set Policy assignment criteria username is <name>. This will prevent the user accessing this specific host as <Block> always wins over <Allow>.
Disabling a (LOCAL) user
Use the Local Users UI to disable a user within the system.
This action allows the status to be set to enabled or disabled.
This will take effect at the next Claims token event (sign-in or renewal).
This allows you to set up access for say a third party user - and only enable it at the time they are ready to access a (protected) host. This differs from Blacklisting which is only possible for active users.
Blacklisting a user
Use the Registered Devices UI to blacklist a user within the system.
Use the Active Sessions UI to blacklist a user within the system.
Use the Blacklist UI to blacklist a user within the system.
Blacklisting prevents a user from authenticating (and revokes the current tokens for a user session). When the user is signed in on more than one active device, the tokens for all those sessions will be revoked and the user's credentials added to the blacklist.This will have the effect of almost immediately cutting off access for the user.
This may be useful when a contractor's current assignment has ended: instead of deleting user details from the Identity Provider database, this option avoids having to re-enter their details if they start another project in the future while preventing access in the meantime.
This differs from a stop Policy (which works at the authorization stage) as blacklisting acts at the authentication stage (and has immediate effect).
To blacklist a user you can:
use the action buttons and select Blacklist User for a specific user in Session Details
use the action buttons and select Blacklist User for a specific user in Registered Devices
use the action Blacklist User and enter a specific user in Blacklisted Users
make an API call to the Controller.
To reverse blacklisting, in Blacklisted Users; use the action buttons and select restore user. Their credentials will be removed from the blacklist and they will again be allowed to authenticate when they sign in using the Client.
Removing a registered device
Use the Registered Devices UI to remove a registered device from the system.
The registration of new devices (when valid credentials are presented) helps to prevent one of the most common forms of breach, namely 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 instance the device count is checked and access will not be allowed if the set limit been exceeded. If this check passes then there is the option to require that users perform MFA at sign-in; either to register a new device (once), or for new and registered devices (always).
Use this option if you want to prevent access from a particular device rather than blocking an authorized user. By removing a registered device from the system and renewing tokens, the current user session will be stopped. The device will now be treated as a 'new device' by the Controller. To configure how new devices are handled by the system refer to identity provider.
Propagating changes to users
Any changes to Policies and Entitlements will be included in any new Entitlement tokens when they expire (and are renewed), or when the user signs out and signs in again. The normal settings for token expiration can be seen in Global Settings. This indicates how long it will be before the change has propagated completely.
The administrator can force a user's Claims and Entitlement tokens to be renewed in real-time. By invoking an immediate token renewal, the token revocation list is updated and pushed out to all Gateways. The Gateway notifies the Client that tokens will expire shortly and will try to get new tokens to replace the expiring ones. The user will be unaware of this renewal process.
Typical situations where changes to user Policies and Entitlements may require immediate propagation are:
removing specific Entitlements for a user
provisioning additional Entitlements
enforcing conditional access to a particular resource
adding a new Gateway on a Site
adding an alert to an Entitlement to monitor network traffic to a particular server
There are several options available for renewing tokens immediately.
In Registered Devices; use the action button Renew Tokens next to the specific user.
In a user's Session Details; use the Actions > Renew Tokens.
In Active Sessions select the users then use Bulk Actions > Renew Tokens
When this is used the rate of token renewal is limited to 6.66/sec, so for 1200 users it might take 3 minutes to happen.
Make an API call to the Controller (which can include the option to renew tokens by Site).
If a Gateway is unable to receive an update (such as token revocation list) maybe due to network problems, then the last list it received is assumed to have a validity period of 12 hours, after which user access will no longer be allowed through that Gateway.