Your manager told you to build an RBAC architecture for an upcoming software project. You have heard this before but never build any on your own.
Don’t worry, in this article, we will cover RBAC with a very simple eCommerce app. Let’s go…
So, In a typical eCommerce application, there are more than 5 business roles.
1. Customer
2. Manager
3. Investory manager
4. Support
5. Subscriber
The roles can go beyond this adding SEO manager, content manager and etc.
Each role has its specific features. That basically means that a customer will not be able to add a new product or change the price of the product but he will be able to place an order.
The way this is implemented is called RBAC, which extends to role-based access control.
RBAC is extensively used in web applications and in this article we will see the process to break down the architecture and make it simpler for your engineer to implement.
Let’s go,
Note 1: This is the simplest approach I have taken to analyze and document RBAC. I looked on google for the same but the articles on the 1st page didn’t satisfy me so I considered writing my own for my future reference and your reference if you consider using it.
Steps to implement RBAC in an application
Before you and your team start coding, make sure to analyze this first. This will save 10s of hours, not hundreds. I learn RBAC permission table making from a 12+ years experience technology consultant who worked with intel(the computer tech company) for 12+ years.
Without further full, let’s dive in
Let’s take an example of a very simple eCommerce, very plain architecture eCommerce.
1. Write the general definition of the application
This helps you set the context and make the document easy to understand for your developer, manager, and other stakeholders. Let’s call this application Shopify.
Description: Shopify is an eCommerce application that allows businesses to create an eCommerce store for themselves. Customers register themselves to browse and buy products and the Shopify team is informed when the product order is placed.
2. Define User Roles
- Admin
- Store Manager
- Subscriber
- Customer
- Support
Once the role is defined, Do a user flow test.
What is a flow test?
A flow test is a process of testing the transaction flow of users from the very beginning .
From landing on the site to browsing products, reading blogs, signing up for blogs, placing orders, canceling orders, requesting refunds, checking refund status, and logging out.
Doing a flow test helps you find any missing features or roles in the application.
In this case, you should do a flow test to see if (1) the Admin is able to add users (2) The store manager is able to add products, the Visitor is able to become a content (3) subscriber (4) the Customer is able to place an order, talk to (5) support, and return, exchange the product, get the refund.
Note: You should do this from the very beginning (Admin to customer). Following the story will allow you to discover any missing features or roles and fix them.
3. Define features
Define features you are willing to have in an application and write them in a table. Something like the following will do
| Features | Identifier |
| Site Setting (Used to change core settings of eCommerce store. ie: Store Status, New Registration, Under Construction and etc) | site_setting |
| Site Customization (Changing Branding, Widget, Menu Items and etc) | site_customization, |
| Products | product_crud |
| Users | user_crud |
| Cart | cart_crud |
| Order | order_crud |
| Blog | blog_crud |
| Ticket (Support ticket created by customers) | ticket_crud |
| Plugins | plugin_crud |
| Themes | theme_crud |
Note: This example is kept stupidly simple to keep it easy to be understood.
4. Make the RBAC permission table
This is fairly simple but requires a details flow test and it’s a good idea to get and 2nd and 3rd glance after you have made the permission table.
| Name | Role | Permission |
| Bob | Admin | site_setting, site_customization, user_crud, plugin_crud, theme_crud |
| George | Store Manager | product_crud, order_crud, blog_crud, ticket_crud |
| Ruby | Subscriber | blog_r{read) |
| Suresh | Customer | order_cru(create, read, update), review_crud, blog_r{read), ticket_cru |
| Glen | Support | ticket_cru(create, read, update) |
crud = create read update and delete
blog_ru{read, update): Ruby, who is a subscriber should not be lower to add or delete a blog article but should be allowed to read the blog.
Permission like blog_r represents that the user can only read the article.
Note: The delete option is not given as organizations like to retain the data for reference than deleting them. The support team should not be allowed to delete the tickets too as a support team may accidentally/deliberately delete the data.
5. User-Specific Flow Test
The reason features are kept in this is because once you are clear with the user, it becomes easier to define the feature by wearing the hat of each user.
The admin has permission to add users, add products, install plugins, change themes, change settings, and change payment information.
6. Overall Organization-level flow test
An organization creates a store to sell its product. That means that starting from installation, configuring admin, adding products, installing themes, and plugins, customizing the store to adding users, inviting customers to place orders, canceling orders, and replacing products to monthly report generation, everything should work smoothly.
It’s very common to find a flow issue or a broken customer journey. In case you find any, fix the flow by adding new features and revise the whole document and do the user flow test and Organisation flow test to ensure that the journey isn’t broken.
A major bug may waste hundreds of expensive engineering hours in doing revision and rebuilding the product. It’s always better to fix the issue and then kid.
I know it’s a time taking process but it really fixes the system for everyone.
