Versions Compared

Old Version 2

changes.mady.by.user Phillip Hanegan

Saved on

compared with

New Version 3

changes.mady.by.user Phillip Hanegan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Version published after converting to the new editor


Div
stylemargin-botton: 30px;

HR-Driven Identity Lifecycle

Many organizations use a Human Capital Management (HCM) system to maintain user data for employees and to initiate all status changes. This includes the pre-hire interview process, start-date, transfers and terminations – all of which are managed and initiated within the HCM. EmpowerID integrates with an organization’s HCM to detect these lifecycle changes and then automate the management of Compliant Access throughout the Joiner, Mover, and Leaver processes. EmpowerID supports all the major HCM systems including any that support the SCIM standard.

Compliant Identity Lifecycle

It is much easier to deliver access than it is to deliver Compliant Access. IT organizations have traditionally seen provisioning technical entitlements as the finish line which leads to overprivileged users, increased organizational risk, regulatory violations, and vulnerability to hackers and malware.

Compliant Access in the Identity Lifecycle is defined as a secure desired state against which a user’s current access must continuously be measured and adjusted. This contrasts with the traditional approach where lifecycle changes are merely a series of triggered scripted events. Compliant Access is defined in EmpowerID using position-based roles as well as policies to detect and prevent risk. The roles and policies are the benchmarks against which all users’ currently assigned access is measured. EmpowerID inventories all an organization’s systems to retrieve the users, roles and technical entitlements to know at any moment who has access to what. The actual inventoried state is evaluated against the desired “compliant” state and risk policies to detect gaps and initiate changes.

Gaps in compliance most often occur based on lifecycle changes made in the HR system. New joiners are quickly identified as gaps due to missing access to which they are entitled based on their roles. Users changing jobs or locations, or movers, are detected as having incorrect access. Meaning, that they are missing some access appropriate to their new position and still have access that is no longer compliant. And the last case are the leavers, these are users that have been marked as no longer with the organization and all their access is considered non-compliant. EmpowerID’s state-based Compliant Access Delivery engine continuously recalculates these variances of actual versus desired and automates the provisioning of new access and revocation of non-compliant access.

Flexible Lifecycle Workflows

No two organization’s Joiner, Mover, and Leaver processes are identical, so a cookie cutter approach is not an option. Attempting to bend an organization’s processes to the configuration options available in most IGA platforms can be a painful process which typically negates the benefits of automation. EmpowerID has unique DNA among all IGA vendors as it was developed entirely on a Business Process Automation or “low code orchestration” platform. In the EmpowerID model, entire processes are described and automated as visual workflow not simply the human approval processes. The unique flexibility of the “everything is a workflow” model allows organizations to maintain their own business requirements for identity lifecycle without compromising or costly and unsupportable custom development. EmpowerID’s Joiner, Mover, and Leaver processes offer common configuration options fitting most organizations needs with the ability to uniquely handle exceptions in the visually designed workflows. The flexibility of this model allows for much greater automation as well enhanced reporting and enforcement of Compliant Access policies.

Automated Provisioning to All Your Systems

The measure of any identity lifecycle solution is its ability to provision and maintain compliant access in as many of an organization’s systems as possible. EmpowerID provides one of the largest libraries of out of the box connectors for on-premise and Cloud systems available. Out of the box systems can quickly and easily be configured using friendly workflow-based processes. Upon completion of a connection the system is inventoried, monitored for changes and ready for automated provisioning and deprovisioning policies. Many of EmpowerID’s out of the box connectors offer much deeper support than is typically available inventorying and managing fine-grained application permissions.

Simplified Standards-Based Connector Development

For systems not supported by out of the box connectors, EmpowerID has embraced the SCIM standard to simplify connector development, deployment, and maintenance for customers and partners. The System for Cross Domain Identity Management (SCIM) is was open standard created to simplify, and automate identity management of users, groups, and devices across Cloud-based applications and services. The basis of EmpowerID’s SCIM support is our SCIM Microservice Connector Framework. This framework is a ready-made SCIM Server Microservice that allows customers and partners to develop SCIM connectors for proprietary applications without knowing anything about SCIM or EmpowerID’s API. Customers and partners are only responsible for their specific application connector code and nothing else is required to expose non-SCIM compliant applications as standards based SCIM microservices. This unique model dramatically reduces the difficulty in developing connectors and greatly expands their utility as they adhere to modern standards for interoperability.




HTML Comment

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

Info

You can edit these filters, as well as the default logic for the Join and Provision Rules that uses to determine whether inventoried accounts meet the criteria for being joined to existing EmpowerID Persons or used to provision new EmpowerID Persons directly from the EmpowerID Web application. Do not attempt to edit them directly in SQL. For the details, see Review Account Inbox Settings.

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.

Code Block
languagesql
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:

Code Block
languagesql
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.

Code Block
languagesql
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:

Code Block
languagesql
themeDJango
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)


Code Block
languagesql
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:

Code Block
languagesql
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

Info

EmpowerID provides several functions that allow you to preview the outcome of the above the Join and Provision functions before enabling those features. To do so, you can run any of the previewing functions in the EmpowerID Identity Warehouse.These functions are as follows.

  • EXEC [dbo].[AccountInboxing_Preview_JoinCandidates] — Allows you to preview which accounts are targets for being joined to Persons

  • EXEC [dbo].[AccountInboxing_Preview_ProvisionCandidates] — Allows you to preview from which accounts new Persons would be provisioned if they are not joined.

  • EXEC [dbo].[AccountInboxing_Preview_Joins] — Allows you to preview the accounts and the Persons to which they would be joined.