Conversion: User-level access control to role-based access control

Situation
A large (13,000+ employee) organization provisions membership of 12,000 security groups at the individual user level and seeks the benefits of Role-Based Access Control (RBAC).

Slideshow (PDF)

Benefits of RBAC

New hires automatically receive position-associated privileges (e.g. “birthright” privileges)
Transferred staff automatically receive new position-associated privileges and lose old position-associated privileges
Transferred staff retain old position-associated privileges for transition period at manager’s request
Improves manager privilege oversight and recertification
Reduces manual provisioning labor for both managers and Identity & Access Management (IAM) department

Solution components

Database (ex. Microsoft SQL Server)
Directory (ex. Microsoft Active Directory)
Scripting (SQL and PowerShell)
Human Resources (HR) System (ex. Infor)

Highlights/Overview
Mining & Analysis
Although there are numerous complex, attribute-focused approaches to mining groups of users for development of roles, none are perfect. An algorithm-determined role cannot be perfectly fitted for use until the manager that is accountable for the role reviews and adjusts the assigned privileges as necessary. There are two essential approaches to accomplishing this review.

Outset review
Under this review approach managers are required to review algorithm-assigned privileges prior to RBAC deployment.

On-demand review
Under this review approach managers review algorithm-assigned privileges as new hires are provisioned.

The on-demand review offers several advantages.

Perceived benefit
Requiring managers to take time away from their own tasks and initiatives to review algorithm-assigned privileges of their subordinate accounts is unlikely to establish a perception that RBAC primarily benefits the manager, although it does. Additionally, forcing the managers to review algorithm-assigned privileges before experiencing any RBAC benefits is unlikely to warrant the investment, in the manager’s perception. Managers asked to prioritize the review will be less likely to invest to the level they might, if they understand themselves to be the greatest beneficiary of accurate role assignments.

The ideal time for a manager to review algorithm-assigned privileges is during their onboarding of new hires or transfers. It is at this window, that the advantage of RBAC to the manager is most evident and this creates the opportunity to establish a virtuous cycle.

As new hires are onboarded, managers that have perfectly-fitted role privileges require less additional provisioning efforts, or even none at all. Managers of teams that are more reliant on individual privileges will be required to request those privileges with each new hire. With each new privilege request, the Identity & Access Management (IAM) department should include instructions for managers of their direct report’s individual privileges and include instructions for conversion of individual privileges to role privileges.

This creates a virtuous cycle, reinforcing the manager’s perception of RBAC as a beneficial time-saving option and continually drawing newly-created individual privileges into roles where appropriate.

Rounding back to the initial discussion of a mining approach, considering that no algorithm-assigned privileges system is perfect, that managers must review the algorithm-assigned privileges at some point to move them toward perfection and that this most effective as a continuous cycle rather than a single instance effort, choosing a less-complex algorithm seems justified.

In this project, privileges that are held by 20%, or more, of the users sharing the same position are associated with the position. The remainder are considered individual privileges and remain assigned to the user rather than the role. The users processed lose no privileges during the conversion, but those sharing the same position (under the same manager) may gain role-shared privileges. Interviews were conducted with managers of various departments to adjust this threshold.

One aspect worth explanation is that the RBAC concept may be more subjective than some realize. RBAC system vendors may describe RBAC solutions that are much higher in organizational hierarchy than the user’s actual position. Systems that describe “roles” at a department or division or even location level may approach the concept of RBAC, but when the privilege assignments do not extend all the way down to the position level, there will be more secondary manual provisioning in the process than necessary and some of the benefits are lost. For example, assigning a handful of privileges to each employee in IT as a birthright is considered by some to be RBAC, but few of the benefits described above would actually be achieved.

A, B & C
The compensation department is the organization’s primary steward for position management. In other organizations this could be an HR function.

New positions are created if an existing position requires pay-grade reclassification. New positions may also be required to support organizational redesigns. Minor title changes may be made to a position without creation of a new position and therefore do not impact the RBAC process. When a position is decommissioned, the compensation department moves all users out of the position in Infor prior to disabling the position.

D
The compensation department notifies the requesting manager of a new position via email when the position is created in Infor. The compensation department agreed to copy the IAM department (step “G”) on these emails, which enables a subsequent interview (step “W”) to assign birthright privileges to the new position.

H & J
Infor and AD are primary points of truth for position and security privilege management respectively.

Positions in Infor are changed by the processes described in “A”, “B” and “C”.

Security privileges are changed during ongoing daily operations as new security groups are created and manual provisioning occurs.

K
A PowerShell script extracts UserID and security group memberships from Active Directory and saves the data in a CSV file. The CSV file is bulk loaded into a database.

L & M
A SQL view combines the position updates drawn from Infor tables with the current snapshot of UserID and security group memberships and indicates for each row of UserID, position and security group a value for a “provision as” column. If 20% or more of the users sharing a manager and position share a given security group, the “provision as” field for that row is marked “ROLE”. Otherwise, the row is marked “INDIVIDUAL”.

By default, when a user transfers into a new role their account is moved during the nightly process described in step “Q”. However, managers may request a transition period during which time the user’s account is maintained in both old and new position security groups. This is accomplished by means of a database table with UserID and position combination exceptions. Exceptions are filtered in step “M” leaving transitional roles in place.

N
A sample CSV file is provided below. This is used in step “Q”.

Q
A second PowerShell script processes changes from both Infor and AD (Refer to Figure 3). The sample CSV provided in step “N” provides the desired AD adjustments. Steps “R” through “U” are performed by the script.

R
New position security groups (ex. “12345111114”) are created in the RBAC OU. New positions receive a default base privilege set by adding the new position security group to “DefaultBirthrightGroup1” and “DefaultBirthrightGroup2” as shown in Figure 3.

S
UserIDs are moved to new position security groups. In the example User03 was previously in position “12345111113” and the CSV file indicates User03 is to be moved to position “12345111112”. Therefore UserID03 is moved as shown in Figure 3.

T
SecurityGroup4 is indicated as a “ROLE” in the “ProvisionAs” column of Figure 2. Therefore, the script moves both position security groups “12345111112” and “12345111114” into the “SecurityGroup4” group as shown in Figure 3.

U
Because UserID02 and UserID03 are now provisioned with “SecurityGroup4” as a role, they no longer need this as an individual privilege. Therefore the script removes both individual user accounts from the “SecurityGroup4” group.

W
IAM Coordinators contact managers who have recently received new positions and manually add additional privileges to the role.

Phasing in the process
The script in step “Q” will only process users and security groups that are listed in the CSV. This approach lends itself to incremental, phased deployment. By filtering (via SQL) the output of step “M” specific users can be targeted for RBAC transition until all personnel are converted.