Role-based access control is handled by Microsoft Identity Manager (MIM) 2016 using the BHOLD suite, which enables organizations to define roles, and to control access based upon those roles. Although we will touch upon most of the relevant topics, this chapter will not be too in-depth, as it takes time and slow steps to understand all the concepts in BHOLD. We will use the synchronization knowledge that we gained while creating MA and the FIM service knowledge to create sync rules to support the basic Role-based access control (RBAC) implementation. The analytics and model loader will not be discussed, as it can take a lot of time to go through all the knobs and switches. The core focus will be the core components that make BHOLD a valuable addition.
In this chapter, we will cover the following topics:
When we talk about RBAC, the first thing that comes to mind are security groups and the managers or owners of the security groups. Now, in the discussion around role-based access, we also use the term discretionary access control, also known as RBAC. But when we look at RBAC, we typically see a lot of security groups in a one-to-one relationship between the organizations and the security groups. This can be okay and manageable for a small organizations, but as the organization grows, these memberships of the groups become really hard to manage, and also to monitor who has access to what. The following image is a classic depiction of this challenge:
So, how does an organization look at this problem? Most organizations use the MIM Service and Portal, but this only helps in automating processes in the groups; it does not solve the overall problem— it just mitigates it. This is where role-based access with BHOLD comes in. We will also talk about privileged access management, but that solves a different problem. In this case, we have many security groups and many users, so let's first start at the problem.
The first thing that needs to be done is to take a holistic view of the organization. Some folks call this an audit, but in reality, this is just a system-wide or organizational-wide review in terms of who has what and who needs what?
This is not an installation that will solve all your problems—it takes time and manpower to begin addressing the problem. Like with any prolonged problem, there is no simple medication, or surgery, or even a quick fix.
So let's take a look at the The Financial Company. The company can be broken down into many different roles—managers, sales, engineers, and so on. We have a multitude of resources that need to be accessed and certain permissions, whether it is the HR staff that needs access to the SQL HR database, or simply to corporate records. Again, the systems can be broad, but in reviewing your role-based access strategy, you will begin to understand your organization's access control needs.
Now, when we talk about RBAC, we also talk about some of the features that BHOLD brings around this terminology. One of those is separation of duties (SoD). SoD is a common practice in the security field that, by definition, means that one user should not hold all the keys to the kingdom. So BHOLD brings SoD to light when you're planning your role-based access strategy. One example of this is that The Financial Company makes a lot of transactions through a payments system, so one separation of duty strategy is allowing only one set of folks to initiate the payment, and then have another set of people to authorize the payment. RBAC allows the enforcement of this type of policy rather than giving one user full control to authorize and initiate the payment. With Privilege Access Management (PAM), this takes a whole new level of authorization where you can have just-in-time authorization for your highly critical assets. Again, the Microsoft Identity Suite offers many tools that an organization can use to include many of the modules that come with BHOLD. Building your strategy using this technology will help you implement the best solution for your organization.
When we talk about the BHOLD role model, we need to understand that we have to define the organizational roles, map the users to the roles, and then also map the permissions to the roles. This is a process that can take some time, and all of these connect to five types of objects within the BHOLD role model. We will outline these objects as The Financial Company is reviewing its role-based model.
Organizational units (orgunits) in BHOLD are the principal foundation to organizing users within the BHOLD role model. When you create a user in BHOLD, you have the option to tell BHOLD what orgunits the user is a part of—so, planning this fundamental layout is important. In most organizations, this might match what their organizational structure looks like in Active Directory, but do not confuse this with Active Directory. BHOLD orgunits should be designed around the organization's business policy. Again, it could match Active Directory, but you need to do the underlying work in discovery to meet the needs of your organization.
Let's take a look at the The Financial Company. The OU structure of The Financial Company is flat—essentially, it is one organizational unit that contains all the users. So right from the start, we know that we have to build our organizational structure for BHOLD. Now one good thing in BHOLD is that you can have multiple organizational strategies. You could have an orgunit for your corporate business, and then also plan your strategy around research and development projects, that is, special projects. The following image depicts the high-level organizational structure of The Financial Company. Again, this is very high level, but we can work with this.
Let's take this a step further. We know that the CFO has a VP for finance and a VP for accounting. Under these, we can outline all the positions that roll up to the vice presidents, which roll up to the Chief Financial Officer within The Financial Company. In the next image we've outlined the positions of the compliance manager, the accounting manager, and, of course, the AR manager and the AP manager. There could be multiple managers as the company grows, and more roles are needed.
Now, this is where you think about the bigger picture, and—could there be a need for multiple people? The Financial Company is a fairly large company, but its organizational structure, from a business standpoint, is very small. However, the CFO is aware that they are bringing in multiple managers, who will, in turn, manage several regions. This is an important piece of information, as you are working through the organizational unit's structure for a long term. With some input from the CFO, we can now determine that we need to break apart the business into regions—this will allow for SoD by region.
As you can see in the preceding image, we only took a portion of the business to start a development process of outlining the core objectives of the business and what they plan to do in the future. This enabled us to build an organizational structure that will meet the business needs in the future as well as the present. This does take time however, and it is important to understand that trying to do everything at once might not be the best plan. Break it down into areas of the business. As you saw, The Financial Company started out with the finance department, because that is their area of highest priority.
We've given you an example of a possible organizational unit structure, but do not limit yourself just to the business side. There may be other areas that you need to address using RBAC. For example, if you want to have an organizational structure for all your project management needs, such as on-boarding new projects, this doesn't have to just be the operating business of the core organizational structure. You can have one-to-many relationships like you see depicted in the following image. To add organizational units once you have come up with your plan, you can use the BHOLD Core web portal or the BHOLD model generator. More information on the model loader can be found at http://bit.ly/MIMBHML.
The orgunit has several settings around roles, the users tied to that orgunit, as well as the supervision roles. The following is a sample image of the orgunit:
As we discussed in the preceding section, orgunits are probably the core guiding factor when we are looking at a role-based model. We know that when we create users, they have to be assigned to the org unit or units. Again, users can be assigned to multiple units, thereby allowing the organization to assign the role to the orgunit, and then allowing the user that is assigned to pick up the role.
You do have the option to suspend a user, but this doesn't mean that you will delete it—it may just imply that the user went away on medical leave, or there may be a business policy that requires to suspend users that go on travel. But in any case, you can suspend a user, which, in turn, revokes all role assignments for that particular user. Once reactivated, it would restore all the permissions granted by that user's role.
Users can be created one by one using the BHOLD Core web portal, or they can be imported just like our organizational units by the model generator loader or the Access Management Connector from the Synchronization service.
Like the orgunit, you have a customization feature in the BHOLD Core web app to apply or add settings directly to the user context. The following is an example view of this:
Roles are the foundation of the RBAC model. In most cases, roles will never be provisioned to the target application unless that application uses its own roles to define permissions. Roles are typically assigned by the organizational unit which the user would be a member of, or by assigning the role directly to the user. In BHOLD, we have inheritable role, proposed role, and effective role.
When a role is assigned to the parent organizational unit, it can be constructed as inheritable and proposed—this means that the role is available for users on request. If the role is constructed as inheritable, but effective, it means that the role would be automatically applied to any user within the organizational unit.
In addition to this, a role can also be activated for the user based on the user attributes. This is called attribute-based authorization (ABA). You can find more about ABA at http://bit.ly/MIMBHConcepts.
A role within BHOLD has a few customizable settings. While some limit the number of permissions and the number of sub-roles, others limit the policies and organization units, as seen in the following screenshot:
A permission in BHOLD is a collection of all the authorizations that were imported from multiple target applications. These include all the Active Directory security permissions, or third-party permissions—within BHOLD, these are called permissions. Now these permissions map from the Access Management Connector with an object type of group. It is critical to understand this concept, because most systems that you connect to may refer to this as another system type. A case in point is that you might have a system that is called a role, but then you have to map it from that application to the synchronization engine, and then back to the BHOLD permission. The following screenshot is an example of what we are talking about:
In the example given in the preceding image, we have a SQL database (1) that has a role object and a person. This is not an Active Directory, but an application that is used by the business, and it is a core essential application for The Financial Company. As you can see, when we bring it into the synchronization engine, it is brought in as group (2). Then once it's in the sync engine, it will be created in BHOLD Core as a permission. So it is easy to get confused, but to draw those variants, any connected system or application, whether it's a role or a permission such as an Active Directory, will always be a group type within the synchronization engine.
Like other objects in BHOLD, you can look at the permission, and the application and roles that the permission is tied to, and modify them accordingly (except the application, which is a hard connection). But most other settings can be updated, as seen in the following screenshot:
Applications are connected to a permission. When you create a permission within BHOLD, associated applications can be created within BHOLD Core directly, or when you create the permission from BHOLD or the Access Management Connector. Just as an example, the following screenshot shows one of the BHOLD permissions. You can see that it's defined the application as B1 by default. When you install BHOLD Core you're going to see the B1 application tied to multiple permissions:
An application is a critical object, as it is where you see all the permissions, and also the stewards. We will uncover what the steward role is in the Attestation section of this chapter:
We touched upon the basic features of RBAC within BHOLD, but we will not to stop there, as there are some advanced BHOLD features that are very important when you're looking at your RBAC model.
The first feature that we will look at is cardinality. Cardinality, in general, is a business rule for that particular role. An example is that you can configure a role limit around the maximum number of sub-roles, or maybe, the maximum number of permissions that can be linked to a role, and you can also configure a permission limit for the maximum number of roles that can be linked to a permission.
The second feature is what we've discussed earlier, that is, SoD. This allows the business to define and prevent users from gaining access to and performing actions that should not be performed by one single individual. In the example we gave earlier, it was all was about initiating it, and then processing. The SoD would prevent this from happening by defining incompatible permissions.
Context-adaptable permissions (CAPs) are another feature that can be applied to applications, permissions, organizational units, and, of course, users. CAPs are a great way to define how the permission is to be applied. For instance, in some examples found online, permissions are granted based on whether the users are a full-time employee or a contract employee. This is, again, the inclusion filter, so by defining if they are part of one group or another, the permission would be automatically applied. This is a great way to have granular permissions based on the current status of the user.
We've already mentioned the feature that is called ABA or attribute-based authorization. Now this is an enablement functionality that allows you to define whether a particular role is activated when all the rules or thresholds apply. This eliminates the need to actively put them as proposed roles for the user. Instead, if the user already meets all the rules, then you can simply apply the actual role without any user intervention or requests. This feature is fine, but there's one thing that you need to know—even if you have any role that passes all variables, you may also have a cardinality setting. For example, if you have a cardinality setting saying you can only apply this role to users within the organizational unit, the cardinality rule wins; therefore, only using it would actually get the role.
Finally, we arrive at our last advanced feature, which is flexible attribute types. Again, this is a great way to extend the attribute-based authorization for users or organizational units, and even for role attributes. Like other components within the Microsoft Identity Suite, you can add attributes to fit your organizational requirements.