The Integration team at Bloomreach has a very well defined charter: Make integrating Bloomreach products as easy as possible. Our primary customer is the IT professional that has been tasked with integrating Bloomreach products into their existing technology stack. Our efforts to make the integration easy generally involves building tooling that either 1-) Streamlines integrations behind the scenes or 2-) Provides more insight and control to that IT Professional. Since the team’s inception, we’ve had a lot of success behind the scenes, but our focus has now firmly moved on to providing tools to empower our customers to be as successful as possible as quickly as possible.
Historically, the process for the user and access management was to contact our support team and file a ticket. This led to a suboptimal experience for all involved, and it really made sense to hand over this functionality to our customers. After all, they know what makes sense for their organization infinitely better than we ever could. Let’s empower them to quickly make the changes that make sense to them. Moreover, whatever tool we build, let’s ensure that our internal support team uses the same tooling we’re providing to our customers. This proved to be an incredibly fun and challenging engineering problem! We have many customers from many completely unrelated industries, which meant that organizational structures varied wildly. We really needed a tool that was both flexible and intuitive enough that could meet the needs of a wide array of customers. This forced us to deal with a lot of assumptions around authorization that none of us even realized we were making.
This post is part of a series in which we’ll talk in detail about the solution we developed and the challenges we encountered along the way. By the end of this first post, you should have an idea of why it made sense to tackle this problem, why the common off the shelf solutions didn’t quite fit our use case and the basic structure of what eventually worked for us.
When we think about authorization, what generally leaps into mind is some form of the question: Is allowed to perform ? This question can easily be answered by a traditional authorization paradigm such as Role-Based-Access-Control (RBAC). At least, it can be, until you become a company with many customers and those customers have many nested sub-organizations that can potentially have organizations nested inside them, etc, etc. To tackle that problem with RBAC, the number of roles you have to support grows exponentially, which quickly becomes painful to manage.
We discovered that our implementation of identity and access management could not be a flat role-based access control system, it had to incorporate the additional concept of an organizational hierarchy.
As mentioned above: Bloomreach has a lot of customers, and those customers typically have several accounts. Accounts, from a Bloomreach perspective, are really just an abstract project. It could represent the entirety of a single customer or just a specific environment that belongs to a customer. From a programmatic perspective it looked a bit like this:
A flat structure, of all the accounts. Some of these accounts are clearly related to each other, but those links were often implicit.
We already had internal, and programmatic access to these links. But more than just a set of links, we really need to take into account our customers' organizational structure. Something that looked more like this:
Bloomreach, from an architectural perspective, is a multi-tenant company. Our customers are also often multi-tenant internal to their interactions with Bloomreach. A global office supply company, for example, has many brands, sites, and org units that all exist under the parent umbrella of the office supply company. This company will want to manage these as if they are separate tenants that they own.
Once this hierarchy was in place, plus the surrounding tooling, our customer could control their users and access. Support would no longer need to create users for one of our customers, a customer with the require roles could create users for their own organization, and grant that user whatever roles that user needed. In the example diagram below, jamie.fakeuser@officesupplies.ca would have the ability to create other users that would live under the www.officesupplies.ca node. Jamie could then grant that new user whatever access they needed.
In addition to Users having Roles at a location in the organizational hierarchy, organization and accounts needed something similar to a role. Each of our customers uses a subset of our product offerings, so those customers should only be able to grant their users access to those applications. Internally, we think of these as PermissionGroups, but we’ll talk more about those later.
The “organizational node” types we support are https://www.sumologic.com/, https://www.sumologic.com/, https://www.sumologic.com/, and https://www.sumologic.com/ and we plan to implement more over time, and we ultimately plan to turn over complete control of a customer's organizational hierarchy to the customer. They shouldn’t have to learn and conform to what we think their structure is, they should define it.
Once we had settled on a design that would meet our needs, we rolled up our sleeves and started hunting for our tool stack. Authentication and password management was already being managed by Auth0, so that was off our plate. We needed to provide good logging and auditing, but since we already used SumoLogic internally it made sense to just plug that in. That left choosing a data store. We tried many approaches including a GIT backed file system (we were already drawing a lot of inspiration from hierarchical file systems anyway!), zookeeper, and home growing our own hierarchical structure in MySQL, before landing on Postgres. Postgres has custom data types that align closely with our needs and enables us to do a one to one translation from concept to data - no hacks involved. In a later post, we’ll talk a bit more in-depth about these tools.
I hope this post gave you a little context about the problems we had to solve, why traditional solutions wouldn’t quite work, and what we decided to do. Keep an eye out for future posts where we’ll dive a little deeper into this architecture, as well as some of the design challenges we faced when trying to present users with an intuitive view of the described hierarchy. We’ll also discuss the Gatekeeper, which is a tool we wrote that actually attempts to answer all Authorization questions before a service is even aware of a request.
Top comments (0)