We’ve had the opportunity to speak to more than a hundred engineering teams over the last year. Hundreds of architects, developers, security professionals and engineering leaders who are looking to either build or enhance an authorization system for their applications and/or services.
We won’t sit here and pretend that we don’t have skin in the game — almost every ‘build vs buy’ article you will read was written by a vendor that clearly wants you to buy what they are selling. But since starting the company a year ago, we have had the unique opportunity to gather a large amount of data about how companies are managing authorization and policy management at their organization.
We have gained deep insight into how hundreds of organizations are tackling authorization by doing two things
- Meeting with over a hundred engineering and security teams ranging from fast growing startups to Fortune 100 companies
- Conducting a survey to find out how hundreds more handle authorization — the type of solution they have (commercial, open-source, homegrown), the resources needed to build and manage it, as well as the challenges they experience along the way
Rather than spending the rest of this post rambling about why buying is the only direction to take, we’ll cover some anecdotal discussions we’ve had in the last year, what we found in our recent survey as well as when it actually DOES make sense to build an authorization solution in-house.
When we talk with engineering teams, we typically see that one of two use cases are usually driving the conversation between us:
- They need to integrate an authorization system for their application and are weighing the benefits of using a commercial solution with building a homegrown solution themselves
- They have an existing authorization system and business requirements now call for more sophisticated, fine-grained access controls and other functionality. In short, they have outgrown what is usually a basic RBAC (Role-based access control) system that they’ve built.
We also realize that there is a third group that exists, whose path we rarely cross: those that have built a homegrown solution and are completely happy with it. Because they aren’t at a crossroads on how they are managing authorization and policy, there’s no business need that would cultivate a conversation between us. With that, let’s talk about when it makes complete sense to build your own authorization solution.
When it Makes Sense to Build
A few years ago I was working at a SaaS company who got to the maturity stage of needing to build RBAC into their product. They needed to give their customers the ability to control what their users had access to in our product. A few weeks after joining build.security, I reached out to the Principal Engineer from the previous company to have a conversation about his experience building RBAC. He had dedicated all of his time over the course of a month to building role based access control at what he referred to as an ‘minimum viable product’ level state. He claimed that he hasn’t had to touch it since it was put into the product and if he had to do it all over again, he would still choose to build rather than buy.
He also mentioned that if he had to build anything more than RBAC, say ABAC (Attribute-based access control) or more advanced access controls, that he would have dedicated more time to finding a combination of open source and/or commercial solutions to meet his needs. RBAC was something of the line he drew in the sand, where, if the business requirements were any more advanced than resources/permissions/users/groups, he would conclude that building it in-house would no longer make as much sense. To learn more about when to leverage ABAC as opposed to RBAC, check out our recent blog post, RBAC vs. ABAC for API Authorization.
It’s these conversations, and many others like them that have given us the opportunity to better understand the business use-cases where it actually makes sense explore building an authorization service in-house. Our conversations and experience have shown us that you can usually get away with building your own homegrown authorization system when:
- You only need basic role-based access control and don’t foresee any circumstances where business rules would require attribute-based or other more advanced access controls. Often times when developers will come to us to talk about how they are managing authorization, they have already built RBAC, and now need to add ABAC and are looking for ways to manage the complexity of doing so
- All of the data that’s needed to make an authorization decision is available to the application at the time when the decision needs to be made. Syncing authorization data between different services in a microservice architecture can present a significant challenge
- Your application’s users do not require the ability to be able to customize user roles and permissions
- The application or service that you are granting access to doesn’t contain any financial, PII, or other sensitive data
- You are granting access to an internal application or service where insider threats around that application or service aren’t a huge concern as there is no sensitive data being exchanged. This obviously contradicts zero-trust, but it’s something we hear occasionally
In the many conversations we’ve had with developers, these seem to be the recurring themes where it makes sense to try at least exploring building an authorization system in-house.
“The most complex technical discussions tend to be around fine grained permissions and authorization. Just like Okta, you don’t want to try to build that thing — you don’t want to do that. It’s a fools’ errand.”
-Senior Software Engineer (large SaaS company)
The Cost of Building Basic RBAC
In the case of the company I worked for above, the cost of dedicating an engineer to build an mvp RBAC system over the course of four to six weeks is going to run anywhere from $15,000-$35,000 in engineering resources. This does not include the cost to build a UI or have the service deployed, but rather solely the engineering time to build system. As the number of engineers dedicated to building authz grows or the time it takes to build it prolongs, this number starts to increase exponentially. Now you might be thinking to yourself, “We can totally build this!” You probably can, but before you start planning, here are some things to consider around the cost (time+resources) for building an authorization system
- This cost assumes the most basic of role based access control systems where you have a very limited number of resources, permissions, roles, groups and nothing more
- In the above scenario, you might be dedicating 10-20% of your engineering resources on a ten person team to tackle this over the course of several sprints. What other value-adding features could that engineer be building for the product instead of building an access control system? Allocating 10-20% of your team over 10-20% of the calendar year becomes a significant investment of very scarce and costly engineering resources
- The cost above only considers the building of an authorization system, but makes no assumption, both for cost or time, of maintaining it. As business requirements call for more elaborate access controls, this cost continues to increase. Buying a boat is expensive. What makes buying a boat even more expensive is the cost to dock, winterize, maintain, and fuel it. So to consider the true cost of what it means to buy a boat, you need to look past the sticker price and the docking fees, and consider a host of other costs that will come into play after you purchase it. Similarly, anticipating the cost of maintaining and enhancing authorization systems ahead of time can greatly reduce headaches and resource constraints in the future.
- Ask yourself – Did you build your own authentication system or did you use a commercial solution for it? If you made the strategic decision to purchase Okta or Auth0, then you have to ask yourself why you would want to build something that is significantly more complex than authentication?
“I ended up having one engineer spend around 1-2 calendar months building out our basic system. It took another few weeks to build the management UI around it. To be honest though, beyond the time and resources that were required, it’s one of those systems I don’t want to have to build at all – not only from a resources perspective, but a risk perspective.”
-CTO (fast growing SaaS company)
The Cost of Building ABAC and More Advanced Access Controls
So if it costs tens of thousands of dollars to build basic RBAC, what can you expect to pay to build something more feature rich and advanced? We surveyed 300+ engineers and architects from fast growing tech companies to large enterprises that have tackled this problem and we begin to have a picture on the cost and staff required to build an authorization system in-house. We were curious as to how many engineers they dedicated to the project and how long it took them to develop the service.
How much time did you and your team spend to build the authorization solution?
- 44.2% of the respondents said that they spent between 10-30 days to build their authorization solution in-house and 30.6% spent between 31-90 days to do so
- 15.6% of respondents spent more than 90 days building their authorization system
How many team members in your engineering/security/IT team were required to build your in-house authorization service
- 37.4% of respondents allocated a team of 3-5 engineers to execute on building their authorization system and 40.4% allocated a team of 6-10 engineers
- 19% of organizations allocated a team of 10+ engineers to the project
- Nearly 80% of respondents identified maintenance of their authorization system as ‘difficult’
- 45% of respondents also claimed that poor access controls have led to data breaches in the past
- Nearly 72% of respondents said they are worried about a potential data breach due to their existing access controls
So what does all this mean from a cost perspective? You can see that when you are allocating 3-10 engineers to this task, the costs could quickly grow from $80,000 on the lower end, and upwards of $500,000+ for a few months of work. And again, this is simply to build and deploy the solution and does not include any maintenance, building graphical user interfaces or making product enhancements.
“Authentication and authorization have been very important. We’ve added these to the application and it kinda worked when it was a monolith, but over the years as it’s become more and more distributed it doesn’t really work.”
-Chief Software Architect (large SaaS Company)
Points to Consider For An Enterprise-Ready Authz Solution
- Flexibility and scale – The most common constraint we see with homegrown solutions is the lack of flexibility and scalability. Teams quickly run into problems when trying to expand their access controls across multiple services, or try to centrally manage their policies across those services. Developing a system that provides both flexibility and scalability as business rules and requirements change usually presents the biggest challenge to dev teams. Flexibility and scalability = increased cost. Every time a change is made or an enhancement is required in your system, costly resources are required in order to fulfill those requests.
- Audit logs – The ideal authz system should provide full visibility into why a specific authorization decision was made and what was the data and the policy at the time the decision was made. Without this functionality, security reviews will be hard to manage
- Impact Analysis – Being able to test policies before you deploy them, and being able to understand the potential impact of those policies is critical. This allows you to ensure your policies are constructed in a way that will yield the results you want without impacting the business.
- Decoupling Policy From Code – You should decouple the policy logic from the application. This is something we’re a big believer in at build.security because it gives you the ability to manage policy across different applications or services that are written in different languages. This is quickly becoming the de facto model to build an authorization solution.
- External Data Sources – There will likely come a day when you want to build access control rules based on third party data sources such as the status of Jira ticket, the type of employee classification in Workday or the Account Status in Salesforce. Leveraging third party data sources means digging into their API each time, understanding their schema and then having to build the systems to facilitate communication between the services
- Policy As Code – It’s important to treat all access control policies “as code” which allows you to review and test them using standard SDLC procedures.
- Performance and Availability – Unlike authentication which is done once per session for a user or a service, authorization checks are being executed for every API call, in a real-time fashion. Because of that, it’s important that the authorization service sits right beside the protected application, providing authz decisions with a low-latency budget and 100% availability.
As we went through the scenarios above, we see there are definitely instances where building an authorization framework in-house can be conducive. That’s not to say it’s decisively the better alnterative, but there are certainly some scenarios where commercial or open-source solutions aren’t the clear winner. It’s a win by points, not by knockout. If you are focused on building RBAC for a single, monolith application that doesn’t contain any sensitive data or there are no foreseen reasons that the access controls will ever need to become more robust, then you can make the case that building a solution is a viable option.
However, if you are working within a mix of distributed, microservices environments or dealing with multiple applications, any number of which contain any financial, PII or other sensitive data, or your policies are looking at third party data sources and other attributes, exploring the use of a third party solution that can centrally control authorization and policy management becomes more viable.
Most importantly, when planning to do either, it’s important to look down the product roadmap to anticipate if or when there might be more feature requests in the future. Also, take time to consider where your development team should be prioritizing their time and valuable sprint points and if you can justify putting access control at the top of that list.