# Surefire Platform Authentication The current response from our authentication endpoint contains information that supports both surepulse and surefireplatform. Some data might be unnecessary for the new ui but are needed to keep the old one working. Here is a high-level overview of the authentication & authorization structure for the new version. ### Users have roles and roles have permissions. Permissions are used to determine what pages/sections can be accessed by a role. A role `admin` that has a permission of `page_leads` would mean that any user with that role can access the *Leads* page in the application. There are some cases where we want to also restrict access not only on the page but also a section on that page. From our previous example, let's say somewhere in *Leads* page, a chart is included that shows the sources of leads and we only want it to be visible for users with `admin` roles, we can do so by adding a new permission `leads_sources_chart` to that role. The permissions for a user depends on what roles he/she are assigned. We *can't customize* the permissions of any given user, instead we add a brand new role if we want a different set of permissions for a number of people. ### UI implementation We simply check the array of permissions from the payload to show/hide components. Given that we store the json response to a javascript object named `user`, we can toggle the visibility of a page using the code below. ```html <leads-page *ngIf="user.permissions.includes('page_leads')"> <leads-sources-chart *ngIf="user.permissions.includes('leads_sources_chart)"/> </leads-page> ``` ### Permissions Edge-Cases There are times where we want to hide pages/sections for clients regardless of role. As for example, we are disabling the *Leads* page for all *Budget Blinds* clients. To do so, we added a `client_permissions` table that will contain all the restricted permissions for a client. #### clients table | id | name | |------|------------------------| | 2356 | Budget Blinds | | 2358 | Budget Blinds of Ajax | #### permissions table | id | name | |------|------------------------| | 1 | page_leads | #### client permissions table | client_id | exclude_permission_id | |-------------|------------------------| | 2356 | 1 | | 2358 | 1 | Our backend is looping every client assigned to a user and excluding the items in `client_permissions` table from the `permissions` derived from the user's `role`. The result will be a new list of permissions inside each array site from the payload. Notice how the `page_leads` permission has been removed from the *Budget Blinds* from a sample response below. > **Note:** We are still keeping the top-level `permissions` array from the payload to avoid breaking the previous implementation on the old ui (aka surepulse). ```json= { "results": { "user": { "permissions": [ "page_leads", "page_advertising", ] "sites": [ { "client_id": 2356, "name": "Budget Blinds", "permissions": [ "page_advertising" ] }, { "client_id": 2356, "name": "Hinkle Roofing", "permissions": [ "page_leads", "page_advertising" ] } ] } } } ``` ### Remnants from the past There are still some attributes beside `permissions` that are still in the payload for the sake of keeping the old ui functioning. ```json= { "user": { "status": 200 "attributes": {}, "enabledServices": {}, "iscoach": false, "client_groups": [], } } ``` #### Attributes Data that was previously coming from LDAP integration. #### Enabled Services Enabled services is a collection of boolean flags of all connections for every client. They are derived from multiple tables, a client connected to yext should have a value of "1". ```json= { "user": { "enabledServices": { "1": { "client_id": 1, "yext": 1, ... } } } } ``` #### Status, Is Coach, and Client Groups [wip]