# Firewall rules

- Link: https://www.agilicus.com/anyx-guide/authorisation-rules/
- Published: 2024-05-14T00:24:07+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. Firewall rules

![role-based-access-controls](https://www.agilicus.com/www/e2df019c-pam-action-plan-
icons_privilege-role-based-access-controls.svg)

## Firewall Rules

Web (HTTP) Firewall Setup

[CONTACT](https://www.agilicus.com/contact-us/)

## Firewall Rules

Identity is “who” a user is.

Authentication is how a user “proves” their Identity

Authorisation is “what” a user is allowed to do. In the AnyX platform this is implemented
via a set of firewall rules. For web applications, these have many options (method,
path, body, who, etc).

The firewall rules are access via “Resources/Applications/Overview”, and then selecting
the individual application, and navigating to the “Security” tab.

![image](https://www.agilicus.com/www/14aedb49-image-1024x624.png)

![image](https://www.agilicus.com/www/7ea1f904-image-1024x645.png)

### HTTP Rules

For web applications, HTTP rules allow matching on a set of conditions, and then
performing a set of actions.

The conditions include:

 1. Priority. Rules are evaluated in order until a match occurs
 2. HTTP Path (the part after the host name in e.g. https://hostname/path).
 3. Method (e.g. GET, PUT, POST, DELETE, HEAD, …)
 4. Scope. One of “Assigned to User”, “Anyone”, “Any Known User”, “Any App User” (see
    [Scopes](https://www.agilicus.com/anyx-guide/authorisation-rules/#scopes) below)

Methods are as defined in the HTTP standard (GET, PUT, POST, …). For most applications
GET/HEAD will mean ‘read’, PUT will mean ‘create’, POST will mean ‘update’, and 
DELETE will mean remove a record.

Actions are Allow, Deny (and None, which can be used to disable a rule temporarily,
or for debugging with logging).

Application Roles are defined per application, but often include ‘Self’ (my own 
records), ‘Owner’ (all, admin), ‘Editor’ (can change but not create/delete), ‘Viewer’(
can read).

Negated (the rule is inverted in sense, so whatever does *NOT* match).

![image](https://www.agilicus.com/www/b6ce9dc0-image-1024x370.png)

#### Scopes

The scopes control what ‘type’ of user is matched by this rule. The scopes are:

 1. Assigned to User. The user must have a valid role within this application, and,
    that role is assigned (see Access/Application Permissions in admin)
 2. Anyone. Literally anyone on the Internet, regardless of who they are (e.g. Anonymous)
 3. Any Known User. Any user who exists in your org as a valid user.
 4. Any App User. Any user who was authenticated by this application (see Authentication/
    Application Identity. **Note** this is a rare case).

### GeoIP Firewall

In some cases you may want to include only, or exclude only, specific countries 
from using a resource. You may do this by selecting the [ISO 3166 country code](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes)
for each locale, and then selecting IN/NOT_IN and action. The most common action(
ALLOW, DENY) would fall-through to the other authorisation rules (ALLOW), or block
entirely (DENY) regardless of user.

![image](https://www.agilicus.com/www/18809fc6-image-1024x273.png)