Glossary of Terms related to Implementing and Supporting Fischer Identity Solutions |
|---|
This section will define useful terminology that is used during construction and post-production support of customer solutions.
| Global Terms | Definition |
|---|---|
| Connected System | A connected system is an integration with a customer's third party target systems. For example, Google Apps, Office 365, etc. Fischer also refers to connected systems as "connectors". A connected system can be a source of data for the Fischer solution to process or it can be a target system Fischer is provisioning to. |
| Identity | An identity is the representation of a user within Fischer. An identity is a combination of attributes that creates an entity within Fischer. Identities can have the same attributes or different attributes as well as the corresponding values associated with the attributes can the different. A Fischer Identity is stored in a combination of tables which will be discussed in detail in our "How a person becomes a Fischer Identity" course. |
| Resource | The "Resource" is the fundamental building block for your entire Fischer solution. A Resource is a component of the IGA Solution that can be acted upon by multiple features. A resource can be an account or an entitlement. A resource is something that be provisioned to Identities and their associated accounts. |
| Account | An account to Fischer is an actual Connected System account. It is not the Identity itself. When referring to accounts, you should consider the context. You should never refer to a user's Identity as an account. Always be sure to distinguish an account from the actual Identity. Accounts are associated with the Fischer Identity. The Identity is not an account. |
| 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. |
| Attributes | An attribute is the fundamental component of defining an identity. Each identity will have a set of attributed stored within Fischer's Identity Registry |
| Identity Registry | The Identity Registry is the location within Fischer where all attributes associated with a particular identity are stored and referenced across very features of the product. The Registry also contains account and entitlement associations to the Fischer Identity providing IGA Administrators and relevant users with a transparent view of which accounts and entitlements are associated with an Identity. |
| Provisioning Hub ("PH") | 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. |
| FUP | 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. |
| FUE | 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. |
| FUA | 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. |
| 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" |
| 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". |
| 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. |
| 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. After Submission, Before Processing... If defined, a pre-process workflow will be initiated AFTER a form is submitted from the self-service portal (multiple features) but BEFORE the engine will process the submitted request. |
| 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. |
| Validation | This is regarding Fischer's ability to perform data validation against form fields for end user facing interfaces. Validation is primarily used in the dynamic UI feature, but in some cases javascript-based validation is required and is built into the forms by Implementations. |
| Group Tree | This is a feature within Self-Service that provides IGA Administrators with the ability to build our a list of requestable resources in an elegant fashion to help the end user navigate through sometimes thousands of potential resources to request access. |
| 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. |
| User Load | The user load feature is what allows the ability to easily load legacy users into the system. In most cases this is used on the initial go live of clients where we need to load all of their legacy accounts into the system. This feature utilizes the sync data feature. The profile data and the accounts of the legacy users are synch'd over into the SYNC* tables. Then you can run the user load feature which will do a poicy evaluation behind the scenes and then checked to see if the user has those in the sync data so that the profile and associated accounts can be inserted into the solution. This feature DOES NOT touch any target systems so it is a fast way of just loading the Fischer tables with the relevant data of legacy users. |
| "Prov Events" | Prov Events is a feature within the administration user interface that provides IGA Administrators with the ability to view details pertaining to a series of different types of provisioning events. The feature breaks down the event into each individual task and/or business process associated with the event. It is an effective troubleshooting tool and is used quite often by those staffed with supporting solutions. |
| Self-Service | Self-Service is a term that is widely used in Fischer nomenclature. It refers to all product capabilities that are end user facing. The feature empowers end users and authorized users with delegated administration capabilities to take actions on their own, without directly involving IT in all requests. By the nature of its name, Self-Service is built to essentially eliminate Service Desk (Help Desk) calls in favor of providing functionality for the end user population. |
| Single Sign On Terminology | |
| IdP | "IdP" stands for Identity Provider. This is a mechanism deployed by customers to enable single sign on. An IdP is simply a mechanism that abstracts authentication from applications and offers a method for users to enter a single set of credentials. The IdP possesses a trust relationship with the applications it is protecting therefore no direct authentication to applications is required by end users when Federation is deployed. The application is trusting the IdP to authenticate the proper user and relying on the IdP to send over the proper information (assertion) to inform the application which user is attempting to access it. Fischer currently leverages a form of the Shibboleth Identity Provider software to offer single sign on solutions and associated features. |
| SP | "SP" stands for Service Provider. A service provider is the application described in the above definition of "IdP". The SP is what end users need to access, and through various configurations (which will be outlined in the Federation guide) the SP entrusts the IdP to authenticate the end user as well as send the proper attributes required so the SP is able to identify the native user stored within its user repository and allow access. |
| Authentication Flow | An authentication flow is a feature of Fischer's IdP. Fischer's proprietary IdP only supports a single authentication flow, which is the custom authentication flow that is used to leverage our dynamic authentication framework to allow for local authentication to occur inside an organization's firewall. This is primarily for our cloud customers that do not want to synchronize their active passwords to Fischer's cloud. |
| EntityID | This is a term used as the component that holds the unique identifier for the SP. While this value does not need to be an FQDN, the majority of the time it is. The EntityID is defined within the metadataproviders.xml file which is where each protected SP is listed for the IdP to reference. |
| Relying Party | The relying party refers to the relyingparty.xml configuration within the IdP itself. This file will also contain the EntityID as a reference to the metadataproviders.xml file and can provide further instructions regarding how the IdP should handle the authentication request. The relying party configuration can include additional instructions regarding encryption, consent, multi-factor, etc. Refer to the Configuring SSO Guide for more information. |
| Data Connector |
The data connector is the defined endpoint within the attributeresolver.xml file where the IdP will connect to in order to retrieve the list of attributes from the server. All Attributes Note that the IdP will return all attributes that are defined within the attributeresolver.xml file. There are other steps in the IdP process that will filter out the attributes that are required to build the assertion for the specific SP making the authentication request. |
| Attribute Resolver | The attributeresolver.xml file is the location where attributes are defined within the context of single sign on. Different attributes may be needed for different SPs, so all attributes that are required for any SP assertion will need to be defined in the attributeresolver.xml file. This file will correlate the name of the attribute in the context of the IdP to the actual attribute it will resolve to in the data connector. |
| Attribute Filter | The attributefilter.xml file is the location where it is determined which attributes will be released from the global set of attributes returned during the attribute resolution process. |
| NameID | The nameID is the unique value that is designated as the distinguishing identifier for the assertion. There must be at least one attribute defined as the nameID in order to move forward with building the assertion to be sent back to the SP. An example of nameID would be the loginID used within the SP to be able to distinguish one user of the application from the next. |
| Callback URL | The callback URL is an important component of any authentication request. The callback URL is defined within the initial inbound request and is also stored in the SP metadata file. It is represented within an authentication request as the "AssertionConsumerServiceURL". Once the IdP has made it to the step where it is building the assertion to be sent back to the SP that requested authentication, the final check performed by the IdP is whether the callback URL sent inbound with the initial request is actually the same one that is stored in the SP metadata. This is a final security check in attempt to thwart any spoofing of authentication requests. If the callback URL is not present in the inbound request or if it does not match what is stored within the SP's metadata, the request will fail. |
| Assertion | An assertion is the process by which the IdP generates the necessary attributes to be sent to SPs so the SP knows which users is requesting access and more importantly what level of access the user will have. The SP controls the assertion requirements because each SP may utilize different Identity attributes to distinguish one user from the next. Therefore, building the assertion (which is the job of the IdP) must be done properly and within context of each individual SP. The SP contains a configuration which includes instructions to be sent to the IdP so the IdP knows which attributes the SP needs to identify the end user making the access request. The assertion process is contained within the IdP, but the definition of what to build and retrieve comes from the SP through a mechanism called metadata. |
| Metadata | Metadata is a configuration file provided by the SP. It contains various instructions and/or requirements for the IdP. Each SP that is integrated into a Federation must have a metadata file it can provide to the IdP. The metadata file is used to configure the IdP-SP relationship which includes the trust mechanism to use (i.e. the encryption signing to be installed within the IdP so the SP knows the inbound assertion is coming from a trusted source IdP) as well as the attributes the SP will accept (or requires to be passed) when it receives an assertion from the IdP. Note that not all metadata will contain certificates to be used for signing. In some cases, the SP will provide a mechanism to download the certificate or provide it to the IdP host. There are also scenarios where metadata can be an aggregate of multiple SPs in the case of entities such as InCommon where SPs can provide their metadata to a centralized broker which contains metadata for multiple SPs. |
| Provisioning Terminology | |
| The Studio | The Studio is short for Workflow & Connectivity Studio. This is the software application that IGA Administrators and Consultants use to construct automated processes. |
| Data Mapper | The Data Mapper is an object within The Studio that provides administrators with the ability to build out business logic in a scripted format and the transform data between different end points that may have distinct schema (for example the Data Mapper is the object that can map SQL syntax to LDAP syntax). |
| Mappings | Mappings refers to the task of mapping attributes TO Fischer's provisioning hub as well as mapping FROM the provisioning hub TO downstream target systems (i.e. Connectors). |
| Mapping Rules | Mapping rules are utilized within the Fischer Workflow & Connectivity Studio. Think of mapping rules as pre-defined, pre-debugged, pre-compiled functions that perform automated actions. Each mapping rule represents a set of functionality that is able to be utilized when building out business logic inside of the Data Mapper. |
| Triggers | Triggers is a technical term and it is a method by which real-time event detection can be enabled for applications that support it. Configuring triggers for IGA solutions is performed within The Studio and will be discussed in more detail in the Workflow & Connectivity Studio Guide. |
| Utility | This term is used for scenarios in which workflows need to be constructed to perform specific tasks within a solution that are not native to the product. Utility processes often utilize the Identity Hub, and/or simply perform data synchronization processes that may not have an Identity context. One example is after Fischer has determined a unique username and/or email address for a particular user and has stored the derived values within Fischer, customer's require that the information derived within Fischer is sent back to the SoA and stored against the user's primary SoA entry. Fischer refers to these types of processes as "Write Backs" meaning we have imported information from the SoA, leveraged the inbound data to build unique usernames, email addresses, etc. and then we export that information out of Fischer's Identity Registry back to the SoA. There are multiple scenarios where utility workflows are utilized and we will discuss them in greater detail in our "How and When to Use Utility Workflow(s) Guide". |
| The Queue | The Queue refers to the Workflow Instance Queue feature within Fischer's provisioning engine. The queue is responsible for determining how and when workflows will execute. This feature is accessible within the administration user interface and while the source code is controlling mechanism that provides oversight and governance related to workflow execution it also offers administrative features for IGA Admins to interact with it for manual intervention if and when required. It also provides visibility to the current state of all deployed workflows within the solution. The queue will be discussed in detail in a separate guide. |
| Deploy, Deployed | This term is used within Fischer to describe where the workflow configuration resides. If a workflow is deployed, this means it is able to be executed by the engine (the server). Deploying workflows is accomplished from the Studio. For the purposes of definition workflows must be deployed to the server before they can be incorporated into a solution. |
| Design | This term describes the a workflow that is not deployed. The Studio is able to be installed locally on multiple machines as it is a fat (or thick) client application. IGA Administrators and Consultants build workflows within the studio in a "Design" state. If a workflow is saved in a design state, that means it is stored locally on the end point it was created and it is not accessible for execution from the server. Only deployed workflows can be executed by the server. |
| GIG | The Global Identity Gateway® (“GIG”). The GIG has two primary functions. The first function is to ensure the communication channel between our data center and your network is secured. To accomplish this, the GIG will require bi-directional communication to/from your network. The GIG resides inside your firewall and typically communicates via port 443. We will discuss the certificate signing process a bit further down in this section. The second job of the GIG is to (locally) communicate with Connected Systems. The fact that the GIG is installed inside the customer's firewall ensures it is communicating locally with the Connected System and not over the wire. The benefits of deploying a GIG will be explained in The Global Identity Gateway Guide. In short, the GIG provides organizations with a secure mechanism to securely communicate with disparate network segments that may not be directly accessible from the subnet where the Identity and Provisioning servers reside. |
| Notifications | Notifications is a feature of the Fischer Suite that provides organizations with options as to how to correspond and communicate important information related to their Identity and any associated life cycle events that occur within the confines of the IGA solution. Fischer supports multiple methods of notification including email (SMTP), SMS and PUSH. PUSH is supported through integrated third party applications and is not directly support within the Fischer product suite. |
| User Match | User Match is a feature within Fischer designed to aid organizations in detecting and preventing the creation of a duplicate identity. User match provides for the ability to configure matching algorithms that will be leveraged during various intake processes available to organizations. If enabled and configured, user match will trap all inbound payloads and execute the defined matching algorithms in an attempt to detect whether or not an Identity already exists within Fischer. The details of how and when to use this feature will be discussed in The User Match Guide. |
| User Groups | User Groups is typically a generic term. In the context of Fischer it refers to the ability to build like users into groups which can then be leveraged to govern how members of a given group are able to function within a Fischer solution. Grouping users is configured within Fischer's Policy Security Administration ("PSA") feature. Once configured IGA Administrators can use groups to govern access to features, functionality as well as provide attribute based access control within the context of the Fischer product suite. User Groups may also be used as a term to describe groups within a customer environment. For example within Active Directory, groups are constructed and members are added when organizations want to locally govern what their user population is allowed to access. This same concept is applicable in the context of how Fischer leverages User Groups within its native security model. |
| PSA | PSA refers to "Policy Security Administration". This is a feature of the Fischer Product Suite that provides governance-related enforcement of the native features and functionality within Fischer. From an IGA perspective, PSA is extremely important as it is THE mechanism leveraged within Fischer to define which Identities are able to perform which actions, including which features are accessible to different Identity types. It can also provide governance over delegated administration capabilities such as enforcing controls that allow for separation of duties within the Fischer product suite. This is an important concept to grasp. Providing native governance features within an IGA product stack is essential if you want to call yourself an IGA vendor. PSA is where true security is enforced within Fischer's application as it pertains to what Identities are allowed to do within the product. This is covered in detail in the Policy and Security Administration Guide. |
| User Management | User Management is a function of the Self-Service feature. It is used in almost all deployments and is directly responsible for configuring Help Desk (Service Desk) related functionality including introducing the vehicle to configure and enforce the defined User Groups and PSA policies built out. All configurable options within User Management will directly affect all end user experiences within the self-service user interface. Refer to the "User Management Guide" for further details on how to build out this feature. |
| Approvals | This term refers to Fischer's approvals feature. Fischer offers the functionality to enable organizations to define automated approval workflows to be executed prior to any provisioning or de-provisioning activities. The approvals feature is accessible via the administration user interface. Refer to the "How and When to Configure Approvals Guide" for detailed information about the feature and it's intended use. |
| Compliance Terminology | |
| Assessment | An assessment refers to a feature of Fischer's compliance engine. Assessments are the act of determining the current state of integrated connected systems in the context of accounts and entitlements. Assessments are used to determine if an Identity is in compliance with the defined access control model. The access control model is defined using Fischer's provisioning policy feature. An assessment will take a real-time snapshot of a Connected System's accounts and entitlements and correlate said accounts and entitlements to a Fischer Identity. If the assessment process is able to successfully associate accounts and entitlements within a given Connected System to a Fischer Identity, multiple methods can be utilized to ensure the Identity is in fact compliant in accordance with an organization's access control structure. The details of the Assessment feature are discussed in "How to Perform a Compliance Assessment Guide". |
| Re-Certification | Re-Certification is a feature of Fischer's Governance & Compliance offering. Re-certification is a process organizations leverage to provide oversight into what access an individual Identity has accumulated over a period of time. Some verticals are required by law to perform re-certification (sometimes referred to attestation) campaigns throughout the course of their fiscal year. The enforcement mechanism that spawned the need for IGA to begin offering re-certification features was the Sarbenes Oxley Act of 2002 (SOX). This law requires specific organizations to perform re-certification and attestation campaigns which forces executives within the organization to understand what employees have access to and more importantly the level of risk associated with different accesses that Identities need to perform their job functions. This was largely spawned out of the Enron case where the corporation was defrauding investors and making themselves look more valuable on paper than the organization actually was. This was done by manipulating the accounting data that was reported to the SEC. Essentially, a group of individuals (including executives) with access to the sensitive accounting material "cooked the books". When you speak about how this was able to happen in the context of IGA, certain individuals had far too much access to the different aspects of accounting and were able to make changes to accounts payable, receivable and effectively manipulate the general ledger which led to the company looking more profitable than it actually was. In turn, this drove the stock price up and investors jumped on board only to find out that in reality the company was not profitable and collapsed overnight. This fraudulent event had such an impact on U.S. markets that the U.S. Government got involved and crafted the SOX regulations. Now, certain organizations are required to review access of each individual within their Identity ecosystem and to attest to and/or re-certify access on a regular basis. SOX spawned the creation of more granular governance features and by default, Identity & Access Management was the appropriate vehicle to provide oversight and enforcement of the process by the nature of what Identity solutions do. When a re-certification campaign is initiated within Fischer, authorized certifiers must manually review access and certify that the individual should in fact maintain the level of access they have. The feature also has capabilities that allows for remediation actions to be taken where certifiers can revoke access if they feel the Identity has obtained too much access or if the Fischer system flags an Identity that has access in excess of the defined access control structure (provisioning policies) that are in place. "How and When to Leverage Re-Certification" is the guide that will provide you with more technical details about the feature. |
| Chain of Trust | The Chain of Trust (a.k.a. "CoT") is a feature that enables IGA and Compliance administrators to define the workflow that certification campaigns will follow. As the CoT is defined it is important to build out a heirarchy that ends with the ultimate authority and person responsible for attesting to (certifying) all access beneath him or her. The CoT allows for delegation of certification to lower-level certifiers while still maintaining oversight and governance from upper management. |
| Certifier | The certifier is an individual granted the authority to certify access within the context of a re-certification campaign. A certifer is able to "Allow" "Deny" or "Reassign" certification tasks during the course of an active re-certification campaign. |
| Tech Reviewer | A Tech Reviewer is an individual granted the authority to certify access AFTER the certifier has completed their tasks. While the certifier may not have the technical knowledge to understand some of the details within the certification task (which is why it is important that the resource description field is filled out so the business-level certifier can understand what they are certifying), which is where a Tech Reviewer can be useful. The Tech Reviewer should be an individual that understands the technical components of the certification task and be able to attest to the technical aspects of the task. Organizations should also consider using the Tech Reviewer strategically for their business process and internal governance. The Tech Reviewer can be leveraged to not only certify the technical components of a certification task, but should also be someone who is able to access the connected system being certified to view the actual access presented by Fischer. This offers a good oversight and checkpoint as organizations are initially deploying recertification as well as on-going campaigns. Regardless if the Tech Reviewer needs to access the connected system, it is Fischer's recommendation that personnel that qualify as Tech Reviewers should have access to the connected system in question to help streamline the business process and maintain continuity. |
| Identity Claiming | This is a one-time use feature that customers will enable when on boarding users into the Identity ecosystem. This feature provides for Identity Verification and ultimate claiming of the accounts associated with the verified Identity. Note that once a user has successfully claimed their Identity they will no longer be able to use this feature. The Implementations team uses this feature or at least recommends that each organization use it for all initial on boarding for new users. Note that you should not confuse this with the User Load or Legacy Load features. This feature is used when Fischer has an Identity provisioned and the actual person is required to claim it through Identity Verification. In the case of the Identity Claim, verification is displaying a series of attributes that distinguish the user so they are able to claim their account. |
| Self-Registration | This is a feature that organizations to use which allows users to effectively register themselves to the organization's Identity ecosystem. Many organizations use this for third party or external users that would not typically flow through the SoAs. There are multiple use cases for this feature which will be discussed in the feature guide associated with "How and When to use Self-Registration" |
| Client Admin | This is a feature that enables a subset of administrative features to be displayed and used within the Self-Service portal. If enabled, a new tab will show up in the Self-Service portal for users or user groups (defined within the PSA feature) that qualify for access. Refer to the "Client Admin Feature Guide" for a list of available administration features that can be displayed and used in Self-Service. |
| Self-Profile Update | This is a feature within Self-Service that enables end users to manage their Identity profile. This feature can be turned on and off, and can also be used dynamically be defining which user groups are allowed to see and use the feature. Governance of the availability of this feature to different Identity types is defined within Fischer's PSA feature. |
| Dynamic UI | Fischer offers the ability for IGA Administrators to build UIs dynamically, without the need to code HTML forms. This feature is accessible within the administration user interface and is used to control the look and feel of the Self-Service facing screens that end users will interact with. This is a drag and drop, forms builder that provides the ability to define custom screens depending on the customer's needs. Refer to the "How and When to use the Dynamic UI Configuration" guide for more details. |
| Security Q&A | This is a feature widely deployed across the majority of the customer base. This feature is the standard challenge mechanism used for Identity Verification that presents a list of questions to end users when they are attempting to reset their password. Refer to the "How and When to use the Security Q&A Feature" guide for specifics regarding how to deploy this feature. |
| Client Org | A client organization is part of a larger feature within Fischer call multi-tenancy. You can read more about Fischer's multi-tenancy capabilities here. |
| Login Alerts | Login Alerts is a feature within the product that enables IGA Administrators to alert users once they authenticate to the Self-Service interface. There are two features involved in the Login Alerts feature. There is a local alert which can either be a custom message you want to alert users about, or it can be an Acceptable Use Policy that users are forced to accept before they can continue into the Self-Service portal. There is also a global alert configuration that is used and is accessible from the master organization. (refer to the Global Administration Guide for details regarding the master org). If a global login alert is configured it will notify all users in all client orgs. This feature is used for communicating global messages such as impending maintenance activities to Fischer's cloud customers. |
| Global Variables | Global variables are by nature, global. Global variables are widely used throughout solutions. They can be defined from the studio or the administration user interface for use in construction of workflows. Leveraging global variables is required when building solutions wherever it is possible. This decreases maintenance when values need to change that may affect a significant amount of workflows and ultimately the customer's solution. |
| Synch Tables |
These are tables that are used to sync data into from target SOAs/Systems in order to use the data in various features. The sync tables are used in the User Load feature, as well as the Compliance assessment and Re certification features. The SNYC* tables are basically a staging ground for the identities, accounts, and entitlements of users within the organization so that you can load them on a new user load or run attestation campaigns. Cannot Delete Data Note that you cannot currenlty delete the data from the SYNC* tables if there are user load instances or re-certification campaign instances out there so you have to delete those first |
| Feature Types |
A Feature Type is Fischer's concept of organizing all product features and giving them a name. Feature types are used to enable IGA Administrators to define a granular authorization model for governing access to product features. All product features are pre-categorized into a finite set of Feature Types. The available Feature Types are as follows:
|
| Compliance Delegates | |
| Attribute Based Access Control (ABAC) |
IHere is the widely accepted definition provided by the National Institute of Standards and Technology (NIST): “ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) actions and the environment relevant to a request. Attributes may be considered characteristics of anything that may be defined and to which a value may be assigned. In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of the object, environment conditions, and a formal relationship or access control rule defining the allowable operations for subject-object attribute and environment condition combinations. All ABAC solutions contain these basic core capabilities to evaluate attributes and environment conditions, and enforce rules or relationships between those attributes and environment conditions” Fischer provides a granular ABAC structure in the context of it's authorization and provisioning policy feature set. |
| Self-Service Terminology | |
| Beneficiary | The Identity(ies) to which a resource is provisioned or de-provisioned. |
| Requestor | Within Fischer, the "Requestor" is defined as the Identity initiating an access request. This can be the beneficiary or it can be another Identity authorized to initiate requests on-behalf-of (OBO) another Identity. The typical scenario is system owners, or managers are provided with OBO privileges to support their end users in a delegated administration model. |
| OBO | OBO stands for "On-Behalf-Of" which signifies Identities with membership to this authorization group to be able to submit and manage access on-behalf-of other Identities. This would include system or application owners managing entitlements for users of their system, managers who create and approve the access profile provided to one of their direct reports as well as help desk users who are required to have the OBO privilege before they can manage end users that contact the service / help desk. |
| Password Management Terminology | |
| Password Policies | Password policies within Fischer is the feature that allows administrators to set the password rules for entropy (including number of upper and lower case characters, must include a number, must include a special character, etc.). This feature can be applied to an individual system, or to a group of systems. |
| Password Enforcement | Password Enforcement, referred to as the "PEC" or Password Enforcement Configuration is a feature that empowers administrators to build out specific password enforcement configurations including the ability to synchronize passwords from one system to another system, define the password policies enforced when a user is resetting his/her password as well as ensuring that end users are |
| Post Password Reset | This term refers to Fischer's ability to execute a process after password resets have occurred. |
| Dictionary | This is the standard term that Fischer users which signifies the dictionary of phrases that are not allowed to be used when end users are setting or resetting passwords. |
| Password Filter | The password filter is a .dll file that is installed on any domain controller (Active Directory) that is in the forest. The password filter will trap the password that is reset inside of Active Directory and send it to Fischer so the solution is able to synchronize the password to other applications (if applicable). This component is largely used when organizations have a desire to maintain continuity of the password across multiple systems as well as for organizations that allow CTRL+ALT+DEL password resets to occur to Fischer is able to successfully be made aware of the password change within the domain and take action accordingly. |
| Kiosk | The Kiosk is a feature used by organizations to allow for self-service password resets. |
| PIN Password Reset | |
| Password Synchronization | |
