Implementing a whole new authorization system can be a daunting task because of the complexities involved. Trying to integrate a new authorization system into the entire application stack in one go is asking for trouble. Not only is it difficult to change the entire stack to use the new authorization system, it's also difficult to test and debug the whole system at once. If the authorization system breaks, it will bring the whole application down.

The solution is to implement a new authorization system incrementally. Most modern applications follow the microservice-based architecture since it is easy to work with a single service at a time. Instead of a full migration, you can add authorization to a single service and debug and test it until you are sure it works perfectly with the new system. You then move on to another service and so on until all the services have implemented the new authorization system. It requires a bit of planning and takes more time than a full migration, but this effort is outweighed by its benefits.

With a microservice-based architecture, you can have two different approaches for your authorization system. In the service model approach, the authorization system is a separate service and the other services communicate with it for authorization. This approach separates the authorization system from the other services, making it easier to upgrade or modify the authorization system separately from the other services. However, the central authorization service can be vulnerable to load during a busy period since it has to communicate with all the other services. Without careful capacity planning, it can create a bottleneck and seriously hurt performance.

The other approach is the sidecar model. In this approach, each service gets its own authorization system. All the authorization systems share the same policy repository to ensure consistency. This approach ensures high performance and scalability, but upgrading or modifying the authorization system requires you to upgrade each service.

The Benefits of Incremental Adoption of Authorization

As touched on already, the incremental adoption of authorization has several benefits.

More Stable

Incrementally adopting authorization is more stable since implementing a small portion of functionality is easier to test. The system is also easier to maintain without breaking the application. Developers have more time to test and verify implemented components, and repeatedly performing tests after integrating each system element increases testing accuracy.

Reduced Time to Market

Incremental adoption is an excellent way to decrease the time to market for an application. As usual, security checks gate application development. Merging small pieces with each release reduces the time needed for application deployment while guaranteeing application security at each step.

More Manageable

Agile best practice suggests that you should not build security systems in one shot. Instead, it’s recommended that you make changes smaller and more manageable, especially since catching defects all at once is most often impossible.

Easier Debugging

Building an application incrementally forces its design to be implemented modularly. It’s easier to build applications incrementally by defining the dependency between different components and resolving these dependencies incrementally, and modularity makes debugging the system easier.

How to Adopt a New Authorization system Incrementally

Adopting a new authorization incrementally should follow the steps below. Iterate these steps periodically for as long as the development process continues.

Note that the first three steps, system and software analysis, researching the tools available, and planning, can't be implemented completely incrementally since they need to be performed once. Some architecture and design decisions will affect the whole implementation/adoption process, and changing these decisions later may be effortful and time-consuming.

Analyse the System and Software

Define the architecture you need to work with. Do you work with authorization as a separate service, or do you need to include authorization as part of each application (sidecar pattern)? What features do you need? This step is crucial as it affects the entire system design and the project.

Research the Tools Available

Once you have decided on your approach, research the available tools to find out which is the best fit for your needs. Determine whether you are going to implement your own solution or whether you are going to use an out-of-the-box solution like that of Cerbos. You can find out more about the tools Cerbos provides for both approaches here. Choose a tool that is the most well-suited for your use case and can easily be integrated with your application.

Plan the Migration Steps

Whether you’re adopting a new system while having an authorization system already running or you’re implementing a new system from scratch, you will need to plan how your changes are going to be made and which services are going to be upgraded first.

Using a standalone and stateless service like Cerbos makes it easier to migrate. If you're following the service model deployment pattern, you can deploy Cerbos as a service. The other services can slowly be modified to communicate with the Cerbos service for authorization. Once all the services are communicating with Cerbos, the previous authorization service can be dropped.

If you're following the sidecar model deployment pattern, you can add Cerbos to each service individually as a sidecar. Always start with the service that has the least blast radius—in other words, if something goes wrong and the service doesn't behave correctly, it should impact as little as possible. For example, if you're building an e-commerce application, a service that is responsible for the rating system is a good place to start. Starting with an important service like the purchase system is a recipe for disaster.

Review and Audit Frequently

As you incrementally migrate to the new authorization system, periodically check the system for bugs and inconsistency. After each service adopts the authorization system, test and debug it before moving to the next service.

Conclusion

This article explained the concept of incremental adoption of authorization, whether you have an old authorization system or you’re implementing one from scratch, and why it’s essential for adopting authorization while building your application in parallel. You learned why adopting authorization incrementally reduces your application’s time to market, increases its stability, and makes it easier to debug. Lastly, you received an overview of a basic plan for adopting an authorization system incrementally.