FD1 Security Model and Authorisation

FD1 systems implement an indepth security model relating to the fact that servers may contain quite sensitive information. Once a user has been authenticated then every request they make is checked to verify if it is permitted due to security rules.

Quick Notes

• Access to each API EndPoint can be enabled or disabled
• Access to complete tables of data (eg suppliers) can be enabled or disabled, allowing read,write,control and delete seperately
• In some cases, you can further refine access to columns within a table (eg only allow "admin" to see suppliers.password)
• Users are granted access to "roles" (eg staff, admin, intern, marketing)
• Roles are granted permission to allow or block resources (endpoints, data tables)
• If a user is allowed access from any role they possess, they are permitted. This applies even if one role blocks access. This makes reasoning about security much easier. example. A user has roles "staff" and "admin". The staff role is blocked from seeing historic products; but Fd1 will allow access as the admin role grants that ability
• Roles can contain other roles, as well as direct permissions. eg "store manager", probably includes the role "staff"
• Roles can conditionally apply. The role "edit customers" might apply only when the user is in specific countries. So a manager on holiday may lose access to edit or even view customers

What can require Authorisation

Data, Products, Customers, etc

Within Fd1, everything is modelled as a table, or 2 dimensonal spreadsheet. Users are granted or denied access to the data seperate to which API they call. Users are either allowed to see something, or they are not. This model is easy for end users to understand, they think in terms of "Bob cannot see accounts"

• Grant or deny to complete tables. Can user XYZ, directly see accounts?
• Grant or deny to columns within a table. User XYZ might be able to directly see product descriptions, but not cost price details.
• [Advanced] Some tables can grant temporary 3rd party access to controlled data. User "Beth" might be blocked from accessing products directly, but is allowed to see historic sales. Viewing a sale without a product description is not always helpful, so "sales" can grant 3rd party read access to product descriptions, without authorising Beth to see all products.

Processing Model

This section outlines how the security is modelled and checked for authorised users. Authorisation rules are processed until a rule either explicitly blocks or grants access.

Step 1 - System wide verification

The first step is to consider the request without considering the user or apikey involved. Rules at this step apply to everyone without exception. These rules are often for things like blocking access from particular IP addresses or Geographic areas. At this stage, the target endpoint "a" is available, but most details of the request are not used.

• Can block all access from IP a.b.c.d
• Can block all access from countries other than X, Y or Z This uses geolocation on IP address, so isnt 100% reliable.
• Intended to work as coarse level controls, so only a small number of rules should exist

Step 2 - User Endpoint verification

The user is checked to see if they are permitted to access the requested endpoint. Enhances step 1 processing to now include user level details. You can block or grant explicit access to end points. All of the details from step 1 are available as well.

• Block "Eve" from fd1.accounts.get_accounts_list This block direct access to this endpoint but eve may still get 3rd party access, such as looking at customer and seeing their associated account.
• Allow "Jane" to access fd1.accounts.get_accounts_list, but only if she is currently in country X or Y.

Output Step

For every value written to the reply from an endpoint, the combination of user, table, column is checked to verify access. While powerful, this can get out of control and result in thousands of rules, so we suggest applying rules to roles, and roles to users. "George" has "store-staff" role, and "store-staff" are blocked from reading customer email addresses.