This article provides the steps and resources to support the task of using the visual policy editor.

The visual policy editor makes it is easy to create and modify access control policies without requiring written policies in JSON. 

Policy Concepts

A policy is a list of statements. Each statement in a policy has an effect, a list of actions and of resources, and an optional rule.

Effect: allow or deny, security is always deny by default; explicit deny allows selective blacklisting

Actions: what the statement allows or denies performing on the resources (i.e. query, delete, execute flow)

Resources: what the statement allows or denies performing the actions on (i.e. a model, field, or flow)

1. Actions and resources allow * to affect all child actions/resources
   
2. Example resource from the Web Frontend Access Control Policy:
   
1. graphql:system:accessControl:currentUser:*
   
1. graphql: Specifies that this is being pulled from the main data API
   
2. system: The module group
   
3. accessControl: The module
   
4. currentUser: The model, which is similar to a table
   
5. *: It is possible to list out individual fields or columns if desired, but in this case there is a star '*' which means all columns will be accessible.
   

Rules: Additional conditional logic evaluated to determine if the statement should apply to the request. There are several types of rules supported:

1. rule: JSONata expression that receives information about the request in the payload (exactly what depends on the action) and returns true if the statement should apply.
   
2. ipInCidrList: A list of IPv4 or IPv6 addresses or CIDR ranges; when the request originates from one of the listed addresses, the statement is applied.
   
3. ipNotInCidrList: A list of IPv4 or IPv6 addresses or CIDR ranges; when the request does not originate from one of the listed addresses, the statement is applied.
   

The visual editor does not currently support rules. To add a rule, make changes in the JSON editor.

Supported Policy Actions & Resources

The following is a full list of supported policy actions and resources, grouped by base.

GraphQL

GraphQL policy statements affect requests to the Application and System APIs, which are the primary APIs for data retrieval and modification.

Actions

1. graphql:query - Read data from application or system APIs
   
2. graphql:create - Create data in application or system APIs
   
3. graphql:update - Update data in application or system APIs
   
4. graphql:delete - Delete data in application or system APIs
   
5. graphql:mutate - Execute custom mutations in application or system APIs, examples:
   
1. uploadFile
   
2. changeCurrentUserPassword
   

Resources

1. graphql:{moduleGroup}:{module}:{type}:{field}
   

Orchestration

Orchestration policy statements affect the Orchestration service, responsible for running Backend data flows.

Actions

1. orchestration:executeFlow - Execute a data flow
   

Resources

1. orchestration:dataFlow:{flowId}
   

Integration

Integration policy statements affect the Integration service, responsible for connection to external systems.

Actions

1. integration:executeConnector - Execute an integration connector
   

Resources

1. integration:connector:{connectorId}
   

# Websocket

Websocket policy statements affect requests to the Websocket-based Subscription API.

Actions

1. `websocket:publish` - Publish messages to topics through a Subscription service Websocket connection
   
2. `websocket:subscribe` - Subscribe to messages through a Subscription service Websocket connection
   

Resources

1. `websocket:topic:{topicName}` - The name of the topic to publish or subscribe to, with periods replaced with colons (e.g. test.name becomes test:name).
   
2. `websocket:dataChange:{service}:{model}:{operation}` - The data change event to subscribe to.
   
3. `websocket:dataChangeNotification:{service}:{model}:{operation}` - The data change notification event to subscribe to.
   
4. `websocket:deviceSubscription:{deviceId}:{subscriptionId}` - The device subscription events to subscribe to.
   
5. `websocket:deviceGateway:{deviceGatewayId}:{functionId}:{requestId}:{request|response}` - The device gateway function event to publish or subscribe to.
   
6. `websocket:device:{deviceId}:{functionId}:{requestId}:{request|response}` - The device gateway device function event to publish or subscribe to.
   

Data change vs. Data Change Notification events

1. Data Change events are published when a model data change occurs. These events contain the data content of the changed model. Consequently, these events should be restricted to prevent accidental information disclosure.
   
2. Data Change Notification events are published when a model data change occurs. These events only contain the name of the model that changed. These events do not contain additional information about the information change.
   

Use the data change notification event if you need to know which models changed. Use the data change event if you need the content of the data change.

Resource wildcards

Websocket resources support two wildcard variants:

1. mid-path wildcards: `*`
   
2. Will match any characters in the segment where the wildcard is present
   
3. `websocket:dataChangeNotification:application:*:create` - Grants access to the `create` data change notifications of all `application` service models.
   
4. end-path wildcards: `#`
   
5. Will match any characters and segments following the `#` wildcard
   
6. `websocket:dataChangeNotification:system:#` - Grants access to the data change events of all operations and models from the `system` service.
   

Screen

Screen policy statements affect the behavior of the Fuuz UI, but do not affect any API requests.

Actions

1. screen:navigate - Access a screen through the Fuuz UI.
   

Resources

1. screen:{moduleGroup}:{module}:{path}
   

Create A New Policy

Navigate to Access Control Policies.

Open the sub-header bar.

1. Navigate to System
   
2. Select Access Control
   
3. Select Access Control Policies
   
4. Open the sub-header bar
   

Click on the pale blue + button to create a new policy.

Alternately, select a pre-existing policy to edit or modify.

Wait for the window to appear.

Type in a Name.

Type in a Description.

Click the blue + button.

Wait for the Details page to open.

Click the blue + icon to add new statements.

Alternately, modify existing statements in the Visual Editor tab of the Policy Editor.

Select a base.

1. GraphQL (all the resources and action permissions except dataflows and connectors)
   
2. Orchestration (executing dataflows permissions)
   
3. Integration (executing connectors permissions)
   

Use the left arrow icon to expand the actions.

Alternately, use the search bar to view the actions.

Check the box or click on the action to select the actions necessary for the statement.

Select the resources necessary for the statement.

Click the blue Save icon save it by clicking on the blue save button.

It is necessary to select at least one action and one resource before saving, otherwise the data will be lost.

Create, Edit, Modify, And Delete Statements

​

1. Select the icon to Allow Permission or Deny Permission (the Allow Permissions state is shown).
   
2. Select the icon to Copy or clone that statement.
   
3. Select the icon to Delete that statement.
   
4. Select the + icon to Add a new statement.
   
5. Use the All Actions box to select all the items in the tree.
   
6. Use the All Resources box to identify the resources in the tree (in Intermediate check mark - few items are selected in the tree).
   
7. Use the Search bar to search for particular action or resource.
   
8. Use the ? icon to show a description of actions and resources present.
   

Change The Permission State

Change the permission by clicking on the icon to Allow Permission or Deny Permission (the Allow Permission state is shown). 

​