Overview of User Provisioning and Identity Lifecycle

Joiner Process

Because of the key role of Person objects in EmpowerID, the process by which EmpowerID joins inventoried accounts to these objects is foundational to how EmpowerID manages your user identities. As mentioned in the Inventory topic, when EmpowerID inventories a resource system with user accounts, it does more than just write a copy of those user accounts to a table in the EmpowerID Identity Warehouse. It evaluates those accounts to determine whether or not they are owned by users, and based on that evaluation it does one of the following three things:

• It ignores them;
• It joins them to existing EmpowerID Persons;
• It provisions new EmpowerID Persons, joining those new Persons to the accounts

The criteria for this process is defined by four database scalar functions that can be customized as needed. These functions are as follows.

AccountInboxing_GetJoinFilter

This function specifies which accounts can be joined to People. To be joined, accounts must meet the criteria specified by the function AS WELL AS the filter specified in the AccountInboxing_GetJoinAndProvisionFilter function. The default logic for this function states that all inventoried accounts are eligible for joining. If the value of AllowJoin was set to 0, no accounts would be eligible.

DECLARE @JoinFilter NVARCHAR(MAX) = N'A.AllowJoin = 1'

This function can be customized by editing the to filter in the web user interface to exclude accounts from being targets for joining to People. For example, if you wanted only those accounts in a specific account store to be eligible targets for joining, you could alter the function in the following way:

DECLARE @JoinFilter NVARCHAR(MAX) = N'A.AllowJoin = 1' AND A.AccountStoreID = 1002

AccountInboxing_GetProvisionFilter

This function specifies the accounts from which Persons can be provisioned. To be provisioned, accounts must meet the criteria specified the function AS WELL AS the filter specified in the AccountInboxing_GetJoinAndProvisionFilter function. The default logic for this function states that Persons can be provisioned from an accounts store when AllowPersonProvisioning is set to true on the account store from which the account originates.

DECLARE @ProvisionFilter NVARCHAR(MAX) =
        N'A.AllowProvision = 1 AND EXISTS(SELECT 1 FROM AccountStore S WHERE A.AccountStoreID = S.AccountStoreID AND S.AllowPersonProvisioning = 1)'

This function can be customized in the web user interface to filter or exclude accounts within an eligible account store from being targets for provisioning new Persons. For example, if you wanted only those accounts with a Department value of Sales to be eligible targets for provisioning new Persons, you could alter the function in the following way:

DECLARE @ProvisionFilter NVARCHAR(MAX) =
        N'A.AllowProvision = 1 AND EXISTS(SELECT 1 FROM AccountStore S WHERE A.AccountStoreID = S.AccountStoreID AND S.AllowPersonProvisioning = 1 AND A.Department = N''Sales'')'

AccountInboxing_GetJoinAndProvisionFilter

This function specifies logic that the above two functions, AccountInboxing_GetJoinFilter and AccountInboxing_GetProvisionFilter, could have in common. This prevents duplicating this logic in the other two functions.To be joined or used to provision new Persons, accounts must meet the criteria specified by the function AS WELL AS the filters specified in the AccountInboxing_GetJoinFilter function (for joining) and the AccountInboxing_GetProvisionFilter function (for provisioning). The default logic for this function ensures that for joining or provisioning, an account must meet the following criteria:

• The account is not currently owned by a Person (The account's PersonID field IS NULL)
• The account is active (The account's Disabled and Deleted fields are0)
• The account is not an Active Directory contact account or a non-personal account (The AccountTypeID field is not equal to 2 and the AccountUsageTypeID equals 1.
• The account has valid FirstName and LastName values (The length of each field is greater than 0)

DECLARE @JoinAndProvisionFilter NVARCHAR(MAX) =
                N'A.PersonID IS NULL AND A.Disabled = 0 AND A.Deleted = 0 AND A.AccountTypeID <> 2 AND A.AccountUsageTypeID = 1
                AND LEN(A.FirstName) > 0 AND LEN(A.LastName) > 0'

This function should be customized in the web user interface in situations where the same filter would be applied to accounts that are both join andprovision targets. For example, if you wanted only those accounts with an EmployeeType of Contractor to be targets for joining or provisioning, you could alter the function in the following way:

DECLARE @JoinAndProvisionFilter NVARCHAR(MAX) =
                N'A.PersonID IS NULL AND A.Disabled = 0 AND A.Deleted = 0 AND A.AccountTypeID <> 2 AND A.AccountUsageTypeID = 1
                AND LEN(A.FirstName) > 0 AND LEN(A.LastName) > 0 AND A.EmployeeType = ''Contractor''

AccountInboxing_GetJoinLogic

This function specifies whether an account can be joined to a person based on the presence of certain corresponding fields between the account in question and an EmpowerID Person. By default, the logic looks matches between the FirstName and LastName attributes. If matches are found, the logic looks for any one of the following matches. If a match is found,(and the conditions of the above mentioned join functions are met), EmpowerID will join the account to the Person. This function can be modified to define custom matching logic.

• EmployeeID

• DateOfBirth

• PersonalEmail

• Email

Mover Process

The Mover process occurs when a person in an organization changes his or her job function and or the organizational location in which they work. The Mover event is important, as access should be reevaluated to ensure that any missing access required for the new role is provisioned and that access no longer needed is removed. A Mover event can be initiated manually using one of a variety of workflows to change a person’s primary Business Role and Location in EmpowerID. These workflows constitute a move and will trigger the reevaluation of RETs and other types of access policies. More commonly, Mover events are triggered based on changes to a person’s job title/code or department ID assignment in the HR system. Typically, these changes flow into EmpowerID via the connector as changes to the External OrgRole (Business Role) and External OrgZone ( Location) assignments for the person's user account. When these change, the EmpowerID Business Role and Location Compiler Job leverages the mappings of these external roles and locations to determine which changes should occur to the person’s internal EmpowerID Business Roles and Locations. If changes need to occur, the job adds the changes to a queue to be processed by the Business Role and Location Processor job.

Leaver Process

The Leaver process occurs when a person’s relationship with an organization comes to an end. The Leaver process is the most security sensitive event as the IAM system must ensure that all access is removed in a timely manner. An unplanned Leaver event can be initiated manually using one of the Terminate Person workflows. These workflows mark the Person object as deleted and trigger a reevaluation of the RET policies associated with that Person object, leading to account deletions or disables.

More commonly, Leaver events are triggered by changes to the ValidUntil field on an EmpowerID Person flowing from changes occurring in an authoritative HR system. EmpowerID provides a configurable “Advanced Leaver” process that relies on a permanent workflow named “SubmitPersonTerminations,” which then calls a child flow chart workflow named “TerminatePersonAdvanced”. The logic for the default process is as follows:

1. The SubmitPersonTerminations permanent workflow runs continuously, calling the Person.GetPendingTerminationNotProcessed stored procedure to collect all EmpowerID Person objects meeting the below criteria:
   • ValidUntil IS NOT NULL
   • AND ValidUntil < GETUTCDATE()
   • AND TerminationBusinessProcessTaskID IS NULL
   • AND Deleted = 0
   • AND IsNUll(PersonOrganizationStatusID, -1) <> 8
     
     
2. Any Person objects meeting the above criteria The EmpowerID Persons—and all user accounts linked to those EmpowerID Persons—are disabled and the PersonOrganizationStatusID field for each qualifying Person is updated to 8, meaning Termination Pending.
3. Next, any Person object with an ValidUntil date greater than the number of days configured for the PersonTerminationGracePeriod EmpowerID System setting is submitted to the “TerminatePersonAdvanced” workflow using the identity set for the TerminsatePersonAdvancedInitiator EmpowerID System setting.
4. As a last step in the permanent workflow logic, the workflow calls the Custom_Person_GetPendingTerminationNotProcessedPendingTermination stored procedure to collect any Person objects matching reactivation criteria. These criteria are as follows:
   • ValidUntil IS NOT NULL AND ValidUntil > GETUTCdate()
   • AND TerminationBusinessProcessTaskID IS NULL AND Deleted = 0
   • AND IsNUll(PersonOrganizationStatusID, -1) = 8
   • AND TerminationDate IS NULL