Last week, I posted about a syndrome I called “trapped in the future.” We often get stuck in this kind of future dreaming, because even if the target we want to achieve is great, the challenge of getting there seems so high. We tend to overplay the characteristics of the ideal solution, imagining the perfect world down to the excruciating details, only to finally drop out of our dream with a long sigh, telling ourselves: “oh yeah, one day…but not today.” And just like people who believe the grass is always greener in neighboring yards, we ignore the fact that, yes, we also have green shoots—the beginnings of a solution—showing up in our own garden.
From Roles to Attributes Via Groups
So in search of how to deliver ABAC today, let’s first examine what we have in our existing security backyard. The current model that is predominant in modern applications is role-based access control, or “RBAC” (of course, every sizable enterprise also has a handful of legacy apps that cover the gamut of authorization concepts from ACLs to DAC). So let’s take a look at the best practices and principles behind RBAC. The two next pictures summarize the story.
First, roles and permissions are defined at design time:
Then, groups are assigned to roles during deployment:
The idea is to divide the authorization process into two steps: design and deployment. And it makes sense because it matches the division of work between:
- The application designers who are in charge of creating the applications and defining the main use cases and the abstract profiles of the people who will be using the application—the so-called “roles.”
- The end users who will be assigned to those roles at deployment time through the groups mechanism. These users carry out their tasks, without tinkering with the applications in any way.
So, in the case of a web access management package like SiteMinder, this division of work shows up in the following policy architecture:
So let’s reexamine what we have. When it comes to authorization, most “relatively” modern security applications (WAM, NAC, etc…) follow the RBAC-model. This approach divides the process into two steps:
- Design, where you define the policies enforced behind each role.
- Deployment, where you assign groups to roles and control access and authorization through group membership.
Since an application evolves relatively slowly—there aren’t new releases of functionality or policy every two days—any changes follow the lifecycle of the application.
From Manual to Dynamic: Making Groups Work For You
But when it comes to the assignment of people to groups and roles, the story is completely different. Change is constant there. Beyond just HR turnover, there are a huge number of projects that can pop up or disappear in response to shifts in the market, and that means that the number of groups is also huge—and the rotation of people inside those groups is important. And that’s the real authorization bottleneck, where the opportunity of ABAC is the greatest, because ultimately, being able to easily dispatch people across finer-grained groups means better enforcement of your current policies.
In my next post, we’ll look at how to evolve from static groups, where members are assigned to groups manually, to a more data-driven system, where your groups could be generated by rules on based on attributes that already exist in your system. The trick, of course, is gathering those attributes, which are scattered across different silos…but that’s a story for another day. 🙂
Be sure to check back!
PS: And if you want the full story today, check out the replay of our recent webinar on delivering ABAC for SiteMinder.