Authorization

Learn how Response decides how to grant or deny access to application functionality.

📘

We're Happy to Answer Questions...

This concept is a difficult one to understand and follow, but is crucial to your success. If you have further questions about how authorization is granted or denied within Response, please reach out after reading this article. We're on Discord!

Roles and Abilities

In Response, access to records and functionality is granted via the concept of roles and abilities. An ability simply corresponds to an action that a user can perform within Response. In fact, abilities themselves hold no actual value; creating abilities within your database that are not tied to a Response function will not provide you with any other levels of access--just don't do it. Since assigning a lot of one-off abilities to users each time would be mundane and prove to be an awful user experience, Response offers the concept of roles.

Roles, by design, perform no actual authorization logic and are only used to group any number of abilities for mass-assignment (read: a better administration experience). This means you are able to fully customize the roles as you see fit and assign them wherever necessary to get the broad or granular level of access you want.

You can learn more about providing access using the built-in abilities in the Providing Access chapter.

Determining Access

Response uses the concept of a pipeline to determine how access is granted. In a typical application, roles and abilities are assigned to a user and the user is used to determine the level of access. This concept works well for typical applications where the user is the single source of truth, but that's not the case for an application like Response.

You may be wondering why Response is different, or you might already have an idea of the answer. The answer isn't that Response was poorly designed--in fact, the design of Response was specifically structured to offer authorization using this exact method. To better understand why, let's run through some fun hypothetical situations.

📘

Quick Note

In these hypothetical situations, we're going to describe the access required in a set of bullet points, we won't use the actual ability names like you would use to provide the access inside of Response yourself.

Situation #1:
A Response instance has two agencies, a Police Department and a Medical District. The Police Department has four ranks: Patrol Officer, Corporal, Sergeant, and Chief of Police. The Medical District only has a single Medic rank. With the layout of our agencies in mind, we need to fulfill the Chief of Police's request to grant specific access based on the rank of the personnel. Here are the requirements for each rank:

Patrol Officer: Being that the Patrol Officer is the lowest rank, they need access to only the bare minimum features in Response to properly do their work. The Patrol Officer must be able to do the following things, nothing more:

• Check out a vehicle
• View the incident board
• Assign an incident to themselves from the incident board
• View assigned calls
• Request route guidance to the assigned call
• Change their own unit status
• Send message to all other units
• See other units on the map
• Search for businesses and other locations on a map and request route guidance

Corporal: Corporals should receive all abilities that the Patrol Officer rank receives, but the Corporal must also be able to do the following things:

• View shift statistics

Sergeant: Sergeants should receive all abilities that a Corporal receives, including the inherited abilities from the Patrol Officer, but the Sergeant must also be able to do the following things:

• Remove a unit from the shift
• Review per-unit statistics
• Check whether units have activated their emergency lights or siren
• Check unit vehicle speeds

Chief of Police: The Chief of Police has all the power and is given access to the remaining abilities not yet given to others.

Looking back, since Response allows us to give access at various levels we were able to specify what each rank could do, but the same concept applies to a number of different entities in Response: Users, Agency Types, Agencies, Skills, and Personnel. We discuss what takes precedence in the next section.

Now, since we have two separate agencies, we can assign the abilities that the Medical District's Medic rank needs, or just assign all the abilities to the entire Agency itself. If we had multiple related agencies we could create an Agency Type and assign our Agencies to that type while assigning a broad set of roles and abilities to the grouping of Agencies, but also assign more granular permissions to each Agency itself.

As you can see, the authorization pipeline for Response is complex and you can customize it at a very detailed level. This level of control is super powerful, but it comes at the cost of knowledge required to efficiently configure Response for you to do the least amount of work possible. After all, that's the goal--being able to use Response more as a user than the administrator.

Order of Authorization (OA)

The Order of Authorization, or OA for short, is the order in which access is allowed or denied in Response. When Response encounters a deny, the request will be denied outright. However, the Response authorization pipeline denies anything not specifically allowed, so there are very few cases in which assigning a deny is necessary. In fact, the only time it might truly be necessary is if you are assigning a high-level allow and needing to explicitly deny only a subset of those with access.

When giving access to different Entities specifically, the access is granted or denied in the following order, starting with the User.

1. User
2. Personnel (Note: This is not the same as Person.)
3. Rank
4. Skill
5. Agency
6. Agency Type
7. Global

🚧

Global is Not Tangible

The Global level is not a tangible access level and is only known in the bounds of the Response application's code. You cannot assign abilities or roles to the Global level.

This level is used for things like allowing a User to change their own password and other owner-managed items, such as allowing a User to manage all People they own.

Using this pipeline, the request will be authorized if any of the Entities in the pipeline have been given the ability either directly or through a role. That being said, if any Entity up to the Entity that contains the ability issues an explicit deny, the access will be denied. Here's a few examples of this flow working.

1. A User is given access to everything, but is also denied from editing other users, the User will have the ability to perform any action except for editing other users.

2. A User acting as a Person who belongs to the Police agency (making them now Personnel within the Police agency) was given access to functionality through their Agency, however, their supervisor has decided to explicitly deny this specific Personnel record access. If a deny was placed on the Personnel record, the access will be denied even though the Agency itself grants the access.