In the early days of on-prem Identity Management (IdM) solutions, deploying "Role-Based Access Control" (RBAC) was often the second phase of Identity and Access Management (IAM) engagements. This approach only made sense after the account lifecycle was automated — cleaning up identity chaos, deduplicating accounts, and assigning ownership of service accounts. While this was standard practice in the past, today's requirements have evolved.

Glossary

Before diving into why most RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) deployments fail, let’s establish some key terms:

Resource: Anything you want to access, such as a document, database, or server.
Action: The operation you want to perform on a resource, like reading a document.
Scope: Filters that narrow down what resources are accessible (e.g., confidential documents).
Access Control List (ACL): Defines what actions specific identities are allowed to perform on a resource.
Owner: The person or group responsible for a resource, from both security and financial perspectives.
Conditions: Additional criteria, such as requiring the user’s job title to be "Director" or higher for access.
Join criteria: The conditions required to assign or revoke access to a resource, like owner approval.

Example: Cashier Role in a Real-World Scenario

Let’s consider a cashier at a fictional Woodgrove branch, using the “Swift Alliance Access” (SAA) application to input (but not release) wire transfer details. This example highlights the practical challenges of assigning business roles in an Identity and Access Management (IAM) system.

Cashier role - right click and chose to open image in new tab for full size image

Assigning such a role can be handled through three methods: automatic, semi-automatic (recommended roles), or manual

The cashier role is a business role, a set of common responsibilities shared by all cashiers. One critical requirement for this role is provisioning an account in the SAA system. However, SAA is deployed in an isolated network, meaning there’s no direct connector for an Identity Management System (IdM) to automate this process. Instead, you’ll need to create a ticket for the SAA Administrator to handle provisioning manually.

Once the account is created in SAA, the administrator must set up roles and profiles. SAA’s internal system roles and permissions further complicate matters. For instance, the cashier might need the following system roles (which consist of several permissions each):

“Create MT5xx for XXXRUMXX”
“Create MT312 for XXXRUMXX”
“Verify MT312 for XXXRUMXX”
“View customer profile”

You also need to apply limits, such as restricting access to specific BIC codes, enforcing a transaction limit of $10,000, and limiting available currencies to USD and EUR. These limits are set within the user profile in SAA.

Beyond SAA, the cashier also requires access to weekly reports from the Woodgrove branch. This necessitates provisioning accounts in Active Directory (AD), MS Exchange, and Entra ID. The cashier’s account must be added to AD DS security groups to grant read and list access to file shares, including the “Woodgrove Weekly Reports” folder. They also need to be included in distribution lists and security groups that provide permissions to Entra ID resources, dashboards, and training modules.

From a technical perspective, assigning this business role should trigger the provisioning of accounts across AD DS, Entra ID, and SAA. While the provisioning into AD DS and Entra ID can be automated, provisioning into SAA requires the manual creation of a ticket. The role cannot be marked as "assigned" until all manual tasks are completed. This necessitates tracking the tickets within an external ticketing system.

So, how do we assign such a role? We have three potential methods:

Fully automated assignments: Roles are automatically and pre-approved for relevant employees.
Semi-automated assignments: Roles are recommended based on certain attributes, but fewer approvals are required.
Manual requests: Roles are manually requested and subject to approval workflows.

Automatic Role Assignments

If you manage to create a detailed role matrix and receive all necessary approvals, automatic role assignments can be a powerful tool. For example, you could automatically assign the cashier role to all active employees who work at Woodgrove, hold the title "Cashier," and have completed mandatory trainings.

However, complications quickly arise. Let’s say your HR department changes a cashier’s title to "senior cashier". According to the role matrix, "senior cashier" doesn’t receive any permissions because the role isn’t pre-approved. After spending time updating the matrix and modifying role assignment conditions, you’ll soon face more title variations like "sr. cashier" or "cashier on duty". This constant churn makes maintaining the role matrix a nightmare.

In response, you might switch from job titles to numeric identifiers like Position PL Codes or department IDs. This can temporarily solve the problem — until HR reorganizes the department and changes all Position PL Codes, causing the system to revoke access for the entire branch due to mismatches in department IDs.

This is why Attribute-Based Role Control (ABAC) often fails: real-world data doesn’t stay static.

But what about other branches? Should we replicate the role for each branch, creating a specific ‘Woodgrove Cashier’ role, or should we divide the role into two, such as ‘Cashier’ and ‘Woodgrove employee’? Unfortunately, there’s no one-size-fits-all solution. Some companies end up with thousands of roles like ‘<Branch Name> Cashier,’ many of which are automatically generated when new branch data is imported. This means your Identity Management system must be capable of importing all branch information and assigning an appropriate role owner for each. To complicate matters further, when a branch closes, you'll need to revoke all related roles — something no IdM system handles automatically. This functionality must be custom-designed, developed, and implemented.

Alternatively, you could split the role into parts, separating access to Swift Alliance Access from the Woodgrove weekly reports. While this approach might work, it would no longer be a cohesive business role, but rather a collection of independent access packages.?

Manual assignments

Manual role assignments give you more control. Users request roles, and the Identity Management (IdM) system checks join criteria before starting an authorization workflow. Approvals may involve multiple stakeholders, such as the user’s manager and the finance department, while ensuring the user has completed necessary trainings.

To prevent roles from accumulating indefinitely, expiration dates should be set (e.g., six months for full-time employees, two weeks for auditors). An access review or attestation process should be triggered before the assignment expires.

The challenge with manual assignments is determining who can request the roles. Should only cashiers be able to request the cashier role? And how should the system respond to job title or department changes? These are policy decisions that need to be clearly defined.

Recommended roles

To ease the load on resource owners, semi-automated assignments can help streamline the approval process. For example, you could eliminate the need for finance approval if the user’s job title is "cashier".

领英推荐

Navigating the Future of Identity Management: Beyond…

Alessandro Banzer 11 个月前

Unlocking the Secrets of Identity Management:…

Fabio Sobiecki 1 个月前

A CISOs guide to IGA-I: What is Identity Governance…

Sameer Sait 2 年前

Additionally, you can limit the list of roles a user can request to "recommended" roles, filtering out irrelevant options and simplifying the user’s experience.

Administering RBAC/ABAC matrixes

The crux of RBAC/ABAC failures lies in the difficulty of maintaining an accurate and up-to-date role matrix. HR reorganizations, new business processes, and security updates can quickly make even the most well-planned matrix obsolete. Data discovery processes, like role mining, are essential for keeping the matrix relevant, but they require significant time and resources.

Furthermore, discovering what resources exist, who owns them, and what access levels are necessary can take months or years. Without a clear picture of available resources, many organizations simply delete old groups and access lists when implementing a new system, creating potential security risks.

But hold on, how do I figure out how to create such a matrix? How do I determine what access cashiers should have, which resources are available, and who owns them? And how many people would it take to keep that matrix current?

Well... that’s an entirely different challenge altogether.

Data Discovery and Role Mining

So, you've decided to build a matrix outlining who should have access to what and why. You've temporarily managed to freeze any changes from HR to the organizational structure. Now, the next step is to uncover what resources are available within your IT environment.

For example, importing users and groups from Active Directory is straightforward (no profiles, no roles, no permissions, no activity groups, no branches, no licenses, only users and groups for simplicity), but understanding what each group does is far more complicated. Even more questions come up:

How do you figure out what a specific group actually does?
How can you tell if an imported group is even being used?
If it is, where and how is it being utilized?
Does it grant read, write, full access, list, or traverse folder permissions?
Or is it perhaps being used to deny access?
Who is responsible for managing that group?
Why are all these users part of that group?
How do you handle nested groups?
And what if group A includes group B as a member, and group B also contains group A?

Well... this requires a separate project altogether. It can take months, sometimes even years. As a result, when an IdM system is deployed, existing groups and access control lists are often overlooked or deleted once the new solution is in place. And by the time you start the assessment, your initial list of resources and groups is already outdated because a dozen new resources were created overnight.

So how do you address this? You need an IdM system with built-in reconciliation that performs a full import at least once a day and a delta import every 15 minutes, for example. This way, you can quickly identify new, unmanaged groups and roles, and generate a ticket for the RBAC administrator to investigate their purpose and ownership.

Additionally, you should run scanners that map out resources in connected systems — whether it’s file folders, SQL instances, tables, SharePoint libraries, or individual documents — to verify that the resources are still properly permissioned and that there aren’t any misconfigured ACLs like 'everyone' on sensitive folders like ‘Annual Promos’.

Are you planning to purchase a separate scanner for this? Or would you prefer your IdM system to include a connector capable of recognizing more than just users and groups? Why don’t we have connectors that import ACLs from subscriptions and resource groups in Entra ID? Do we even fully understand who has access to what and what permissions are being granted through membership? These are all important, rhetorical questions.

Ownership management, escalations

Once you've mapped out your resources, the next step is identifying who owns each one. Ownership is critical for maintaining security, but what happens if an owner leaves or transfers departments? Establishing procedures for transferring ownership is crucial to avoid gaps in governance.

Now, the key questions become:

How do I identify the owner of every resource?
Do I need to maintain a list of resource owners, or should I only track the owners of the groups that manage access to those resources?
What’s the procedure for handling ownership changes when an owner leaves or transfers to a different department? Do I reassign all resources and groups to their manager? To the new manager? The previous manager? What if no manager was assigned in the first place? Should IT security take over until the ownership issue is resolved?
How do I ensure that the current owner is still valid, especially if there haven’t been any organizational changes for a long time?
What happens when an owner is on vacation, sabbatical, or on sick leave? Who should handle pending approvals? How quickly should unanswered requests be escalated, and to whom? What if the escalated approver doesn’t respond?

There’s no one-size-fits-all playbook for these scenarios. The value consultants bring lies in the years of experience they’ve spent answering these kinds of questions, even though the solutions may not always be immediately obvious.

Handling Exemptions, Guests, and Partial Role Approvals

Let’s say you’ve successfully gotten your RBAC matrix with recommended roles approved, your role and resource mining processes are in place, and then you receive an unusual request: someone asks for the ‘Woodgrove Cashier’ role but doesn't need access to the weekly reports. Or, a cashier from another branch is temporarily working at Woodgrove, and the role owner doesn’t want to grant access to MT312 messages, only allowing MT5xx entries. What do you do?

The first issue is that the substitute worker doesn’t see the ‘Woodgrove Cashier’ role as recommended because their department and branch IDs don’t match. To solve this, you adjust the catalog to show all roles and treat the requestor as a guest, requiring extra approvals. But can you approve only part of a role? Technically, it’s possible to approve specific permissions tied to the role. The real question is whether your IdM system supports that level of flexibility.

However, this creates complications when generating reports on access. Now, you must report based on individual permissions and system roles, not just the broader business roles.

Partial approvals introduce another challenge: enforcing role incompatibilities. Initially, the ‘Shift Manager’ role was marked as incompatible with ‘Cashier’ because a shift manager can release transactions, and you don’t want the same person both entering and releasing transactions. Now that the substitute cashier is partially approved and can’t access MT312 messages, should you temporarily assign them the ‘Shift Manager’ role since there’s no conflict? It depends. Ideally, you’d unpack both roles and compare incompatible permissions, but in most real-world scenarios, this type of request would likely be denied.

To complicate things further, let’s say you modify the role to add one more conflicting permission, another incompatible role, and a new permission that grants access to a SharePoint library with ‘Woodgrove All-Hands Photos’. How do you handle it? Do you assign this new permission to everyone currently holding the role? Apply it only to new requests? Revoke all conflicting roles immediately? Perhaps raise a Segregation of Duties (SoD) violation ticket with IT Security and Finance? Who decides whether to roll back the change or revoke the conflicting role that isn’t ‘Cashier’?

And as a consultant, my favorite response to these kinds of dilemmas was always: "It depends".

Access Packages instead of Roles

Now that we’ve established that automatic assignments and partial approvals often don’t work well for enterprises (though they may be suitable for educational institutions or government agencies), let’s explore a potential solution to address some of these challenges.

If you break down the 'Cashier' role into smaller, more manageable parts and reassign ACLs to your resources, you can likely use Access Packages to achieve your goals.

In the case of our fictional cashier, the access packages might look something like this:

Access to Swift Alliance Access via Remote Desktop
SAA Enter and Verify MT312; USD, EUR; Limit 10k
SAA Enter MT5xx
SAA access to common BICs
Woodgrove weekly reports

The 'Woodgrove Weekly Reports' package, for example, would trigger provisioning of accounts in Active Directory (AD DS), Entra ID, and mailbox creation, along with additions to various security groups and distribution lists. Each package would have its own set of owners, join criteria, and relevant parameters.

You would also need to reconfigure access control lists (ACLs), since many of your file shares, folders, and libraries likely have specific security groups assigned. The aim would be to minimize the number of security groups by leveraging access package groups wherever possible, making management simpler while maintaining security.

Nothing prevents you from creating business roles that consist of access packages, allowing for partial approval at the package level rather than individual permissions.

While this doesn’t solve all the problems, it does provide a more structured way to aggregate system roles and permissions. Some may refer to these access packages as 'project groups,' but that’s not entirely accurate.

The Importance of a Trusted RBAC Administrator

In a surprising twist, if I were to don the hat of a hacker or conduct a penetration test like I used to do, my targets would likely not be the accounts of executives or system administrators. Instead, I would set my sights on gaining access to the Identity Management (IdM) or Role-Based Access Control (RBAC) admin account. Why? Because this individual wields ultimate control, overseeing not just admin accounts but the entire system. Even with Privileged Identity Management (PIM) or Privileged Access Management (PAM) in place, the issue remains unresolved. After all, there’s nothing to prevent an RBAC admin from whimsically granting “full control of everything” to an innocent-looking package labeled “all hands photos.”

Ultimately, the success of any RBAC/ABAC system relies heavily on the competence and trustworthiness of the administrators who manage it. These individuals have control over all access, including administrative accounts, making them prime targets for malicious actors. Hiring an underqualified or untrustworthy administrator is a critical mistake that can jeopardize the entire system.

What do I do?

No Identity Management (IdM) platform, solution, or service can single-handedly resolve your business challenges. Even with ready-made configurations, there’s no magical “make it look nice” button. While AI can assist in generating recommended roles tailored to individuals, departments, or organizations, it doesn’t offer much more.

What you truly need is the right tool that meets your specific requirements, but before that, you must establish a clear plan and vision — both of which are unique to each customer. Therefore, Phase 1 should focus on creating a document that outlines this vision and develops all relevant policies on paper. Only after securing approval from all stakeholders — business, HR, IT Security, and IT Operations — should you begin the implementation process.

Shut up and take my money!

Putting jokes aside, the primary reason for most failures is often customers dictating what needs to be done and how it should be executed, while consultants eagerly cash in their checks and deliver what was requested rather than what’s actually needed.

This phenomenon occurs in the engineering field as well.

Previous: Part 6: Engineering challenges - Connectors

Next: Part 8: IAM People Management challenges

Eugene Sergeev