Introduction

The purpose of this guide is to provide an overview of the iHub component of the Fischer Identity Workflow & Connectivity Studio.

Overview

iHub is a workflow component that provides a layer of user management without having to understand the specific repository structures required by the Identity platform. This layer of indirection allows for seamless user management without needing to re-initiate source of authority events or target systems exports to provide updates to the user’s identity record.

This guide will answer the following questions:

• Who uses the iHub component?
• Why do they use it?
• When do they use it?
• What can it do?
• How does it do it?
• Where example workflows be found?

Who

iHub is typically used by solution administrators and implementation engineers to provide an extra layer of control over a user’s identity information. This control allows these administrators to effect data changes within the Fischer Identity solution without having to recreate the initiating event. By doing so they can quickly react to and resolve common data related challenges as outlined in the “When” section below.

Why

In certain scenarios it is necessary to manage certain elements of a user’s identity to either address a solution issue or mitigate a potential data consistency situation.  In the past these scenarios would be resolved by updating the specific product data base tables that contained the information that needed to be updated.  Fischer saw this as a hindrance and a potential point of corruption that threatened the stability of not only the platform, but the solution customers relied upon for the IAM needs.  To mitigate this Fischer developed the iHub component (API) that provides the ability to manage the following from within a workflow that can be operated from with the Fischer Identity platform.  This not only provides a way to manage this user related data without needing to know the specific table schemas and structures, but provides for a consistent experience regardless of the specific requirements as defined by the business.

These user management scenarios are as follows:

• Profile Attribute Management
• Account / Entitlement Association
• Security Question & Answer Management
• Email Alias Attribute Management

When

The question most folks ask is why would you ever need to manage the information contained within the Fischer repository?  Isn’t that what the solution is for? In most instances the answer would be yes it should .  The reality is that there are the following scenarios under which solution administrators and implementation engineers can and will decide to utilize the iHub component to either speed up implementation times or to address as solution issues. 

These scenarios are as follows:

• To address user identity data corruption or sync issues related to the accuracy of the data loaded into the solution during the initial phases of the customer’s implementation.
• User data loads of identity account / entitlement information for users that are not contained within an organizations source of authority.
  • Contract Workers
  • Student Workers
  • Temporary Access
  • System / Service Accounts
  • Last Password Reset Date
  • Specific / Unique answers to the solution defined Security Questions

What

The following will outline the Fischer recommended / standard iHub workflows and their uses, please note that while these workflows have been tested and optimized to meet the expected solution requirements of the majority of Fischer Identity customers, they can be modified and re-deployed if necessary to meet specific business objectives as defined by your business leadership .

IHUB01-Manage-Identity

The following workflow is used to update the attributes on a user’s Identity. This workflow can be chained (executed) from any other workflow within the solution. This workflow ends in the Identity Hub ( ) with the “ExecutionMode” set as “Identity Load.” By using this mode, the object knows the appropriate APIs to use to update the FISC_USER_PROFILE (FUP) table for the attributes that you send into the workflow.

IHUB02-Manage-Account

The following workflow is used to update account related information tied to a user’s Identity. This workflow can be chained (executed) from any other workflow within the solution. This workflow ends in the Identity Hub (  ) with the “ExecutionMode” set as “Account and Entitlement Association.” By using this mode, the object knows the appropriate APIs to use to update the FISC_USER_ACCOUNT (FUA) table for the attributes that you send into the workflow.

IHUB03-Manage-Entitlement

The following workflow is used to update entitlement related information tied to a user’s Identity. This workflow can be chained (executed) from any other workflow within the solution. This workflow ends in the Identity Hub ( ) with the “ExecutionMode” set as “Account and Entitlement Association.” By using this mode, the object knows the appropriate APIs to use to update the FISC_USER_ENTITLEMENT (FUE) table for the attributes that you send into the workflow.

IHUB04-Manage-SecQA

The following workflow is used to update account related information tied to a user’s Identity. This workflow can be chained (executed) from any other workflow within the solution. This workflow ends in the Identity Hub (  ) with the “ExecutionMode” set as “Sec Q&A Update.” By using this mode, the object knows the appropriate APIs to use to update the security questions and answers within the solution.

This workflow is typically used when we do a process such as reclaiming a user, where the help desk clicks a button that would allow the user to go back to the state prior to when they claimed their account. One (1) of those items that needs to be done to get to that state is to clear out any security questions/answers that are set for the user.

IHUB05-Manage-Alias

The following workflow is used to update email alias related information tied to a user’s Identity. This workflow can be chained (executed) from any other workflow within the solution. This workflow ends in the Identity Hub ( ) with the “ExecutionMode” set as “Alias Initial Load.” By using this mode, the object knows the appropriate APIs to use to update the aliases within the solution

How

The iHub component is utilized within a workflow defined process.  This process is managed from within the Fischer Workflow and Connectivity Studio application. As described above the iHub component can be used for a variety of user management events.  The specific details of the implementation of these capabilities and the implementation details of how to utilize the iHub component can be found in Identity Suite Administration Guide – Volume 1 – Chapter 12 .

Examples

While many of the iHub workflows outlined in this document are deployed by default within your Identity implementation, additional ones maybe released as new versions of the suite are developed. If they are not deployed within your environment, please contact Fischer support ( support@fischerinternational.com ) to obtain a copy of the latest versions of these iHub capabilities.

For a glossary of terms used throughout this article, please visit Glossary of Terms