When we start talking automation and provisioning, there are a lot of terms that you'll hear us use. The list below will give you a solid understanding of what we are talking about.
| An "Entitlement" |
| An entitlement is the level of access an account qualifies for. Entitlements can be a database role attached to a database account, or a membership in a security group within an LDAP system, or any type of permission that an account qualifies for, given the type of Identity the user is within the organization. |
| The "Provisioning Hub" |
| Fischer's provisioning hub is a normalized Identity Schema that is used throughout the product. The provisioning hub schema is the "language" of Fischer's provisioning engine, as well as multiple other features within the product to resolve attribute values to the actual data itself. Fischer's features leverage the PH schema for performing all functions to identify users within the context of the feature that is deployed. There is a specific guide that speaks in detail as to the different uses of the Provisioning Hub schema. For now, just understand that all inbound data mappings from a customer's environment is mapped into the PH to normalize the data so Fischer is able to process it through it's various features and functionality. |
| F.U.P |
| FUP is an acronym for FISC_USER_PROFILE. This is the database table where all attribute values associated with an identity are stored. Fischer may refer to this table as "FUP" by either enunciating the acronym as is, or by referring to the table via the individual letters. F-U-P. |
| F.U.A |
| FUA is an acronym for FISC_USER_ACCOUNT. This is the database table that will store the account-to-identity relationship. This table also creates a 1-to-1 relationship between the Identity's accounts. So if a user had 20 accounts, there would be 20 distinct rows in this table. |
| F.U.E |
| FUE is an acronym for FISC_USER_ENTITLEMENT. This is the database table that will store all entitlements a particular account are associated with it. This table creates a 1-to-1 relationship (meaning one row per entitlement-to-account association). So if a user has 10 accounts and each account has 2 entitlements there would be 20 rows in this table. |
| The "SoA" |
| SoA stands for "Source of Authority". This translates to the source of data that Fischer requires in order to initiate processing Identities through the product. Typically the SoA is a series of database views but it can also be a seamless integration with a source system. You may also hear the term "Source of Truth" and it can be used interchangeably with Source of Authority. When building an automated solution, it is required for the customer to provide an SoA as this is the initiation point for Fischer to detect activity within the customer's environment, specifically when new users are added or modified. This is a building block of an automated solution if the customer wants end-to-end automation built into their solution. It is also important to note that Fischer can also serve as an SoA for the creation of Identities. The concept to grasp with regards to SoA's would be it is the initiation point for Fischer to process the user and turn that user into a Fischer Identity. |
| "Staging" |
| Fischer's staging schema and intake process is purpose built to consolidate SoA data from multiple sources of authority to build a single identity record to be sent to Fischer's engine for processing. There are multiple staging scenarios and configurations that may come into play depending on the SoA ecosystem customers require Fischer to use. More details will be discussed in the "SoA Staging Guide" |
| A "Workflow" |
| A workflow within Fischer is related to the automated processes built out within the Workflow & Connectivity Studio. While the use of the term workflow is applicable to other features such as "Approvals", it's primarily used to describe building out automated provisioning, and data synchronization workflows. This term may also be used to describe utility workflows. Workflows have multiple types and those types will be discussed during the detailed "Workflow & Connectivity Studio Guide". |
| A "Policy" |
| Most often when referring to a "Policy", Fischer personnel and SMEs are referring to provisioning policies. This configuration is accessible via the administration user interface by clicking on the "Prov Policy" tab. Note that sometimes the word Policy may also refer to Password Policies as well as internal Policy Security Administration. |
| "The Identity Hub" |
| The IdentityHub object provides a mechanism for creating Identity profiles, accounts and entitlements, and updating the respective FISC_USER_* tables (FISC_USER_PROFILE, FISC_USER_ACCOUNT, and FISC_USER_ENTITLEMENT) and FISC_USER_*_REL tables (FISC_USER_ACCOUNT_REL and FISC_USER_ENTITLEMENT_REL) through execution of standard workflows without configuring the provisioning policy. Multiple uses for the iHub will be discussed in our "When and How to Use the Identity Hub Guide" |
| "Pre-Process" |
|
Pre-Process is a workflow that can be used as needed when constructing solutions. There are various scenarios where it can be used. The concept is that a pre-process can execute within self-service before screens are rendered. For example, we allow only numbers in the phone numbers so we strip everything else out. Other more advanced solutions may have logic based on the original value of like an email attribute to remove it from some repository table. Note: If defined, a pre-process workflow will be initiated AFTER a form is submitted from the self-service portal but BEFORE the engine will process the submitted request. This is done so that logic can be applied to the request prior to submitting it to the provisioning engine for processing. |
| "Post Process" |
| Post processing is the ability to execute a separate workflow after policy evaluation has completed. There are various features that leverage the ability to call a post process workflow. For the most part, this workflow is used to update the staging schema after a workflow has completed. There are more scenarios which will be covered in the "How and When to Use Post Process Workflows" guide. |
| "Legacy Load" |
| This term refers to the process by which a customer's solution is initially loaded with all legacy users. Legacy users are those that existed prior to Fischer's solution taking over IGA activities within an organization. This process will result in all users residing in the incumbent IGA Solution to be loaded into Fischer. The load process will create the user's identity as well as ensure that their current account and entitlement associations accurately reflect their current state. This load provides for a seamless transition between IGA solutions so that users do not lose any access to what they currently have while Fischer is transitioned to production and the incumbent solution is turned off. |