EmpowerID defines functions as “business-defined activities that a person can perform within one or more applications.“ They are objects that organizations create to represent what users can do in their IT systems using the everyday business language of the organization. An example of a function within an organization could be the act of creating a purchase order within a much larger purchasing business process. As mentioned earlier, in SAP the terminology for this right is notated by the TCode, ME21N. To represent the right in a more user- friendly way, the organization could create a function named “Create Purchase Order.”
Figure 1: Native System Entitlements VS Functions
Using functions as the building blocks of what users can do in technical systems, organizations then build their risk policies around those functions using their own business language for those functions and policies. Once functions are named, business process specialists and technical application specialists map those functions to their representative entitlements in their respective applications. Once the mapping is complete, the risk management engine can be enabled to run on a scheduled basis to return users with functions.
You have two types of functions in EmpowerID, global functions and local functions.
Global Functions
Global functions are objects that organizations create to represent the native system rights that delegated users can be granted to perform actions within one or more applications. Depending on the business language of the organization, examples of global functions could include “Create Purchase Orders” or “Create Groups.” Global functions are “system agnostic” as they could represent rights in more than one application. For example, “Create Group” is an act that users can do in numerous applications like ServiceNow, AWS, SAP, Salesforce and EmpowerID. This action can be represented in EmpowerID with a single “Create Group” global function.
Figure 2: Global Function that represents an action that a user could perform in multiple systems
The first step in using Functions is to define what actions users can perform in an organization’s applications and to create global functions to represent those actions. Once created, global functions can be used to contain local functions.
Local Functions
Local functions are children of global functions and represent an action that users can do in the actual entities, systems, and locations scoped within an organization’s business structure. You add local functions to global functions to logically link the generic actions that users can do in applications to the actual entities, systems, and locations where they can do them. In this model, “Create Groups in Austria” could be a local function belonging to the “Create Groups” global function or “Create Purchase Order in SAP Prod” could be a local function belonging to the “Create Purchase Orders” global function. As shown in Figure 3 below, you can add as many local functions to a global function as makes sense.
Figure 3: Relationship between local and global functions
Function Mapping
In and of themselves, functions are nothing more than empty containers that represent actions that users could do within your IT environment. To have use, they must be mapped to specific rights and roles that EmpowerID inventories from your connected applications. In EmpowerID, this is known as adding “function mapping rules” to functions. Function mapping occurs first at the global function level and then at the local function level.
Global Function Mapping
At the global function level, function mapping involves adding to the function the global rights, global roles and local functions that logically represent what users with the function could do. For example, if you create a global function named “Create Azure Groups” that you want to use to see who can create groups in Azure, you should only add to the function those function mapping rules that relate to creating groups in Azure. We can see this in figure 4 below, which shows some of the function mapping rules for the “Create Azure Groups” global function in the EmpowerID Web interface.
Figure 4: Function Mapping Rules at the global function level
From Figure 4, we can see that there are three function mapping rule types:
Global Rights Granting Function (Mapped) – Specifies the global rights, if any, related to the function. In this example, the global rights would be those rights that give someone the ability to create groups in Azure.
Global Roles Granting Function (Mapped) – Specifies the global roles, if any, related to the function. In this example, the global roles would be those Azure roles that give someone the ability to create groups in Azure.
Local Functions – Specifies the local functions to be derived from the global function. All local functions should be related to the parent global function. In this example, a local function could be “Create Azure Groups in Austria.”
Local Function Mapping
Local functions are created by adding them to global functions as function mapping rules. Returning to the “Create Azure Groups” global function as an example, if you want to know who could potentially create groups in an Azure tenant in Austria, you could add “Create Azure Groups in Austria” to the function as a function mapping rule.
Figure 5: Local Functions as Function Mapping Rules
Once the local function is added to a global function as a function mapping rule, you can then map the function to the local rights or roles specific to it. Local function mappings include the following possibilities:
Local Rights Granting Function (Mapped) – Specifies the local rights, if any, related to the function. Local rights that can be mapped to local functions are dependent on the global rights mapped to the parent global definition. A right that is not mapped first in the parent global function cannot be selected for the local function.
Local Roles Granting Function (Mapped) – Specifies the local roles, if any, related to the function. Local roles that can be mapped to local functions are dependent on the global roles mapped to the parent global definition. A role that is not mapped first in the parent global function cannot be selected for the local function.
Assignees Granting Local Function (Mapped) – Allows you to specify one or more EmpowerID actor types with the function. Actor types can include:
Business Role and Location – All people belonging to the Business Role and Location will be flagged as having the function
Group – All people belonging to the group will be flagged as having the function
Management Role – All people belonging to the Management Role will be flagged as having the function
Management Role Definition – All people belonging to the Management Roles derived from the definition will be flagged as having the function
Person – The specified person will be flagged as having the function
Query-Based Collection – All people belonging to the Query-Based Collection will be flagged as having the function