By no means should the reader think that what I am writing in this article is written in stone. Probably, along the way, I will change a lot of things and rethink what I have proposed. This series of articles will guide you through the process of developing something real application. From my experience, things change A LOT, and that is not a bad thing, but knowing that beforehand will make you aware of risks that involve trying to predict everything.

Now that you are aware of the possibilities of change, I will briefly describe what I am building and its requisites.

The Functionality

Any real system has an Authorization component that blocks or allows a user to perform certain actions depending on its clearance. Such a component is usually accessed by other components within the system, meaning the user will rarely interact with this component. That does not mean it is the least demanded; almost any functionality will check with this component if whoever is requesting it is allowed to do that.

1. An authenticated user makes a request to a service

2. This service calls the Authorization Service to check if the user has permission to perform such action.

3. Authorization answers allowing or denying the access.

4. Service process request if the user is allowed

5. Service responds to the user.

Basically, each and every protected action will access the Authorization Service, making it a highly requested component of a system. The Authorization Service must keep track of all requests in case of an audit, and it must perform all the checking super fast; otherwise, all other services will suffer.

One might think of embedding Authorization tags into an access token such as a JWT. I do not think this is a good idea since a user might keep a valid toke for a few minutes, and sometimes, it is necessary to block access to a feature immediately. Also, depending on the number of features or the complexity of the authorization scheme, embedding that much information within a token may not be feasible.

Requisites

The proposed system will be fairly complex, which will give me the chance to explore some nuances and design choices that a super simple implementation may lack.

1. Given a User and a feature, the system will manage the access level:

   1. Read, Write, Delete, Admin

2. Features will be grouped into Entities

3. Entities may be grouped into Subentities

4. A User may have access to a feature through direct permission or through a Role assigned to it.

   1. The highest access level will be considered

   2. Permissions in a Role are not copied to the User.

5. Every permission change will be logged.

6. Every permission check will be logged

7. The system must generate reports with access filtered by:

   1. Entity, Feature, User, and Date

8. Users with Admin access can:

   1. Grant access to other users

   2. Create Entities and Subentities

   3. Request Reports

This is a high-level overview of the Authorization Service that serves as a good starting point. This is probably what a consultant would bring to the table after a meeting with a client. In the next posts, I will describe the system's architecture, its main components, and the reason why we are choosing such architecture.