Introduction
Many organizations implement some form of role-based access control for their access model in Identity Security Cloud. Role-based access control (RBAC) has long been an industry standard for managing user access. Users are granted access based on the role or function they perform in the organization. The minimum amount of access that would enable an employee to perform a specific function is bundled into a role according to the principle of least privilege. Roles can be automatically assigned by membership criteria supporting birthright provisioning. The criteria for role membership is usually based on attributes that are known about the employee such as job title, department, or region. For example, a bank teller in a financial institution needs access to three different systems. A role can be created that bundles this access. The membership criteria for the Bank Teller Role could be as simple as jobTitle="Bank Teller". When a new bank teller is hired, the role is automatically assigned, and the bundled access is provisioned. The new bank teller gets access to the required systems on day one without any manual intervention from IT, and everyone is happy.
Challenge
The previous Bank Teller Role example was obviously oversimplified. In the real world, we deal with much more complex scenarios and systems. An actual financial institution could potentially have hundreds or thousands of locations domestically or even internationally. Depending on what access rights a given bank teller at any of those locations requires, a unique role would need to be created. For instance, if there are localized groups in Active Directory for each bank location, a role with those specific entitlements would have to be created. That could amount to thousands of roles, and that’s just for the bank teller position. What about the other positions at the bank like loan officers, personal banking managers, branch managers, assistant branch managers? Thousands of roles would have to be created and maintained. What happens when a new system is onboarded and new entitlements need to be added to all those roles? We can see that maintaining that enormous volume of roles can get overwhelming very quickly. The traditional RBAC model dictates that all identities who meet the role membership criteria receive all the associated access. But this paradigm is exactly what leads to incredible role sprawl for organizations that need a lot of flexibility in role design.
Solution
There has got to be a better way to create and maintain roles that allows for needed flexibility and reduces role proliferation. Well, there is! SailPoint introduced Dynamic Access Roles at Navigate 2024. Dynamic Access Roles is a revolutionary way to implement complex role-based access control by providing the ability to selectively assign access to members of a role based on the evaluation of contextual attribute values, known as dimensions. This allows a single role to replace large numbers of roles by encapsulating the context information and access policies that are needed to assign the right access to the right members of the role. Remember our Bank Teller Role that had to be duplicated for each bank branch location (possibly thousands!)? It can now be collapsed into one Bank Teller Role with a location dimension. Based on the value of an identity’s location attribute, the appropriate location specific entitlements can be assigned to the identity. This model offers incredible flexibility such that some access that all bank tellers need regardless of where they work can be granted to identities where jobTitle="Bank Teller" and specific access can be granted based on the identity’s location. If location=Manhattan, then the AD group ManhattanPrinterAccess can also be assigned, but if location=Brooklyn then the AD group BrooklynPrinterAccess can be assigned. We can add other dimensions like override permissions, wire transfer limit, and cash withdrawal limit so that each bank teller who is assigned the Bank Teller Role is granted unique, specific access. Up to 1500 different dimensions can be defined on a role. We can see how powerful this dimensional role definition paradigm can be for many types of organizations like retail, medical, and higher education. But really any organization, large or small, that has complex and context-sensitive access policies required can benefit greatly from this feature.
Use Case Scenario
Let’s take Dynamic Access Roles for a spin in ISC! Instead of the financial institution example, let’s pivot to a medical institution. Our demo organization will be a Texas hospital network with facilities in Austin, Dallas, and Houston. Instead of building out multiple nurse roles for all the types of nurses who work there like oncology, cardiac, OBGYN, ER, NICU, ICU, and then creating each of these specialized nurse roles for each hospital location, we will create one nurse role with multiple dimensions so that the proper birthright access can be assigned automatically. Depending on seniority level, our nurses will require different access as well. Our nurse role dimensions will be location, specialty, and seniority level.
When creating a new role, we have the option of Standard or Dynamic:
We select Dynamic for the Nurse role, and now we need to choose the identity attributes that will serve as our Dimension Attributes:
We choose the Location, Department, and Job Title identity attributes, which correspond to our dimensions of location, specialty and seniority level, respectively:
Now we can define the Dimensions and the access that should be granted based on specific values:
We’ll create the Austin Location dimension first:
To define Dimension Criteria, we can choose any of the Dimension Attributes that we have already defined: Job Title, Location, or Department:
We choose Location because that is our corresponding Dimension Attribute and add our relevant location value, “Austin”:
Our next step is defining the access that should be granted for the Austin Location dimension:
We search for entitlements starting with “Austin”:
We add the Active Directory group Austin-BasicAccess to the Austin Location dimension:
We repeat those equivalent steps for the Dallas and Houston location dimensions:
If we were to enable this role right now, then all identities in the Austin, Dallas, or Houston locations would get the assigned access, but we want to limit role membership to nurses and assign some nurse specific access to all members of this role who are actually nurses. We can achieve this by defining membership criteria and assigning access based on that.
Under Define Assignment we specify that the identity attribute Employee Category must equal “Nurse”:
Under Mange Access, we add the Nurse-BasicAccess Active Directory group:
After enabling the role and applying changes, all nurses will get the Nurse-BasicAccess entitlement, but only nurses in Austin will get the Austin-BasicAccess entitlement that was defined on the Austin Location dimension.
Florence Jones is a nurse in Austin:
She was assigned the Nurse role because the value of her Employee Category identity attribute is “Nurse”:
We see that Florence has been assigned the Nurse-BasicAccess entitlement because she met the Nurse role membership criteria, but she received the Austin-BasicAccess entitlement because her Location identity attribute is “Austin”:
Let’s add a few more dimensions. First, we create the Seniority dimension that grants the Nurse-AdminAccess entitlement if the Job Title dimension attribute is “Nurse Manager” or “Nurse Charge”:
Then we define the Nurse OBGYN dimension that grants the Nurse-OBGYN entitlement if the Department identity attribute is “Nurse-OBGYN”:
After applying changes, we look at Margie Fontaine, who is a charge nurse in Dallas and works in the labor and delivery ward:
Margie has been granted the Nurse-BasicAccess entitlement because she met the Nurse role membership criteria, but she received the Dallas-BasicAccess entitlement because her Location identity attribute is “Dallas.” In addition, she received the Nurse-AdminAccess entitlement because her Job Title identity attribute is “Nurse Charge” and the Nurse-OBGYN entitlement because her Department identity attribute is “Nursing-OBGYN”:
So far we have only defined one criterion for each dimension, but multiple criteria can be defined per dimension. For example, to get the access defined under the Houston ICU Access dimension, a nurse would have to be in the Houston location and part of the Nursing-ICU department:
Esther Summerson happens to meet that criteria, and we see that she has been granted the Houston-ICU-Access by the very dynamic Nurse role in addition to the other access granted by that role:
Conclusion
We have seen just how powerful the new paradigm of Dynamic Access Roles is for reducing roll sprawl and creating truly dynamic roles. The amount of time and resources this feature will save an organization is astronomical. Creating and maintaining thousands of roles can be a thing of the past. But if you are happy with your current RBAC implementation in ISC, it’s not going away! Dynamic Access Roles are meant to enhance an existing traditional RBAC program, not replace it if that’s not a business goal. This feature is included in ISC Business Plus, and the focus of the initial release was birthright access with limited certification support for Dynamic Access Roles. So much more good stuff is planned, so stayed tuned to the Product News category!
