Many of our customers use Role-based Access Control (RBAC). At least that’s what they are telling us. But our products don’t actually support the traditional concept of roles, where you create the perfect role of a salesperson and assign permissions and access to that role. Our customers are getting more granular than that.
It’s almost like they are referring to responsibilities as roles. They are creating a set of responsibilities that a salesperson might need and assigning permissions to that. It is a lot more granular and a lot more accurate than trying to create the perfect role where every single salesperson gets the exact same permissions.
The problem is that is a lot more work than just saying all salespeople look like this and get these permissions. A lot more work. So you have to balance IT’s need to have an achievable result without hiring a workforce of thousands with the business’s need to have granular permissions to reflect the real world that they work in.
That’s where we come in. If you look at these “responsibilities” as security groups, it’s easy to get granular. Each salesperson gets some set of group memberships based on what they actually need. But it doesn’t have to be difficult, the majority of these group memberships can be query driven through GroupID Automate. You simply define as granular of a query as you like (department=sales, location=des moines, quota achievement >= 100). As you can see the dynamic group will query Active Directory AND any other data source(s).
For the rest of the groups that you can’t create with queries, offer self service. Assign a workflow so that the group owner or the helpdesk has to approve the request to join the group, put a good description and understandable name on the group, and let your user opt in or out of groups. This takes IT out of the business of figuring out who has to be in the groups and just doing the technical part of assigning permissions.
At least this is what we’ve found with a somewhat self-selecting set of customers. But we know that over 90% of all organizations use Active Directory security groups to manage permissions and access. This method can lead to token bloat if there is a large number of permissions that each user needs; in one sense the dynamic groups help since users are taken out of groups they no longer qualify for (in the example above, if their department or quota achievement changes). The other solution is that group lifecycle policies will expire the security group if the group owner doesn’t renew it.
We can also create a system of role groups and resource groups that I will discuss in part two of this post (coming tomorrow).
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.