Authentication Rules

The Fischer Suite offers an extensive set of configurable authentication options.  Dynamic authentication provides IGA Administrators with the ability to control where and how users will authenticate to the product.  By "where" we mean that certain identity types can authenticate against a different authentication store.  By "how" we mean that administrators can define a set of authentication rules that distinct groups of like users must follow.  Furthermore, Fischer's Identity-as-a-Service platform supports localizing authentication to the organization's existing (protected) credential store on premises without the need to store those credentials in Fischer's cloud.  This guide will provide you with a detailed overview of Fischer's dynamic authentication features.

Authentication Rules

Fischer offers multiple self-service interfaces that require identity verification and authentication.  The Identity Kiosk is a feature that organizations can deploy as a centralized source of on boarding new Identities as well as offer it as a mechanism end users can utilize to reset a forgotten password.  The feature will adhere to a series of authentications rules.  The authentication rules configured for the Kiosk are for the second factor of identity verification.  The first factor is the user must provide their primary username.  Once the user enters their username, the second authentication step is able to be configured to provide the end user with a choice of how they would like to verify their identity.  Fischer's authentication framework is extensible and includes multiple options for IGA Administrators to configure.  The product supports defining primary authentication rules.  Primary Self-Service Authentication rules govern the 1st factor of authentication for end users.  This feature is specific to Self-Service and geared towards your standard end users access.  This feature provides IGA Administrators with the ability to build distinct user groups and configure separate primary authentication policies for each group.  For on premise deployments, administrators can filter identity types to authenticate to independent credential stores.  This provides organizations that deploy Fischer with granular, attribute-based-access-control (ABAC) authorization services to control how their user population is required to authenticate to Fischer's Self-Service portal.  This feature allows organizations to maintain their current credentialing strategies and security model and does not force them to change to a proprietary model.  An example that describes how to best deploy this feature is the case where an organization may have multiple domains that have distinct user populations.

Below is a screenshot of Fischer's authentication framework configuration interface:

Functionality Review 

The following section will help you to understand all authentication configuration options available from Fischer's dynamic authentication framework.  The feature is broken down into four (4) distinct sets of rules empowering IGA administrators to control how different types of identities authenticate.

The first item to determine is which connected system will be used for Primary authentication requests (as defined in the Self-Service Primary Authentication Rules" section explained below.  This configuration is the first item that appears on the authentication configuration screen and is seen below:

The system currently selected is the "Identity System" which is Fischer's proprietary LDAP backend.  If the Identity System is selected, then all authentication requests will utilize the credentials stored within Fischer's Identity system to authenticate users to the Self-Service portal.  This option equates to setting the default, native authentication store that will be used.

Self-Service Primary Authentication Rules

Defining authentication rules at this level will control how end users authenticate to Fischer's Self-Service Portal.  What you see above is a single layer of authentication defined for a particular user.  Fischer offers scalable concepts enabling administrators to build static authentication rules for individuals (as see above) or the ability to govern authentication for defined user groups.  This is configured via the "Rule Type" combo box.  This box offers a "Dynamic" and "Group" option.  When "Dynamic" is selected, administrators must define the actual rule inline.  As seen above a rule has been constructed to enforce mobile authentication on the user listed above.  In this case, only this single user would be required to follow the defined primary authentication rule.

It is important to note that defining Primary Authentication Rules is essentially eliminating the core Identity password when Mobile or Facebook is selected from the Auth Type drop down list.  If System is selected, the primary authentication rule configuration will rely on the defined system listed in the "Default Primary Authentication and Identity Lookup Systems".

This configuration is listed above the Self-Service Primary Authentication Rules and is global to any Auth Type that is set to "System" as the form of authentication to utilize for a given user or group of users.  This feature is extendable and can scale to meet more granular authentication configurations as well.

The next screenshot will showcase how a second authentication rule was added to the Self-Service for a group of users, "Security Administrators".  Notice that the Auth Type is set to system and we have specified a distinct system to use for authenticating this group of users that is vastly different from the initial, static configuration for a single user.  See below:

The ability to distinctly define different authentication groups and the actual credential authority for authentication users is applicable to all subsequent authentication configurations you will see below.  This provides you will ultimate scalability as it relates to how you need to deploy authentication across your IGA ecosystem.

Kiosk Authentication Rules

The Identity Kiosk is a feature leveraged to both on board new Identities as well as help users to reset their password.  This is a stand alone feature that can be deployed by organizations.  The focus of this article is to help you understand the different Identity verification methods you can employ to decrease your risk and offer defense in depth when attempting to verify the Identity of the user.  The authentication feature functions much like the "Self-Service Primary Authentication Rules" in that it offers the ability to define distinct identity verification workflows depending upon a user or group of users.  When deploying the feature, it is best to consider the risk associated with the user accessing the kiosk.  For example, you may want to elevate the authentication workflow for executives or administrators and offer less verification factors for standard end users.  This is just a single example to help you understand the capability you have when it comes to identifying unique Identity types and how you are able to govern verification distinctly.  Here is a screenshot of the configuration:

You'll notice the same configuration options for Rule Type and Rule.  However the options for Auth Type are a bit different.  You'll see 3 distinct checkboxes that can be selected.  The kiosk will utilize however many options are selected.  Let's go through the available options and how it will affect the end user experience.

Secondary Authentication Rules (a.k.a. "Multi-Factor Authentication")

The power of this feature mirrors the power of defining distinct primary authentication rules.  IGA Administrators can govern their entire user population and define a specific secondary authentication rule for different identity types.  This is especially useful for organizations that may have procured an enterprise MFA solution for a sub-set of the user population because they could not afford or did not want to invest in ability for all users to leverage a single enterprise MFA solution.  For this reason, Fischer offers multiple MFA options.  This provides organizations options to deploy an enterprise solution for administrators and/or internal users, while leveraging a free method such as TOTP for the remaining user population to help control costs, while still providing defense in depth to their entire user population.  Fischer provides a separate configuration component for defining secondary authentication rules.  These rules are applicable to the entire user population, including administrators and governs access to all authenticated interfaces.  It is important to remember that you understand that Fischer supports multiple MFA solutions.  

It is important to note that any defined secondary authentication rules are enforced globally across all interfaces of the Fischer product.  This is important to realize as you begin to define and configure your authentication ecosystem for your organization.  Here is a screenshot of the Secondary Authentication Rules configuration:

The following options are available as a form of Secondary Authentication or Multi-Factor Authentication:

Federation Authentication Rules

Fischer supports organizations that are members of a Federation and we extend our dynamic authentication capabilities to where Federated users will authenticate.  Federation has a slight deviation from Primary Authentication Rules in that Fischer's Identity Provider must be deployed to protect your applications.  If the Federation is local, meaning an organization has decided to leverage a Federated approach to authenticating their users as a mechanism of Single-Sign-On, then the defined authentication stores do not require the use of Fischer's Global Identity Gateway ("the GIG").  The majority of time, the use of Federation authentication rules is in concert with the deployment of the GIG.  The result of deploying this feature is the same as defining distinct Primary Authentication rules for Self-Service.  We will discuss how Fischer's Dynamic Authentication architecture extends to providing IGA Administrators with the power to extend their authentication beyond the network segment where the Fischer IGA Suite is running.

Note that you can specify which Connected system to use to send authentication requests to.  This option provides organizations to leverage their de-centralized authentication stores and still provide a centralized, easy to configure Identity Provider.  The caveat here is you must leverage Fischer's Identity Provider feature to take advantage of this authentication configuration.  You'll see that you can set a condition.  This condition relates to the "Rule" above, where you can define distinct user populations to resolve to the defined condition, which will in turn send all IdP authentication requests to the defined connected system.  You'll also notice that second factor authentication is also built into the Fischer IdP.  Currently SMS, Duo Security, Mobile (Fischer Authenticator) and TOTP are supported protocols for MFA when authenticating to Fischer's IdP.

Local, Secure Authentication Framework using the Global Identity Gateway

The primary use of the GIG in the context of authentication is for Fischer's cloud customers.  However it is also available to on premise deployments as well.  The concept in the cloud, is very powerful and allows cloud customers to keep their identity credentials inside their firewall and the GIG will make a local authentication request.  The process will entail the end user entering their credentials into the Fischer IdP or Self-Service interface.  Once this happens the credentials are encrypted within Fischer and Fischer's Dynamic Authentication framework identifies the end users within Fischer's Identity Registry and looks for specific instructions regarding where to send the authentication request.  These instructions come from the configured authentication rules as well as the associated Connected System. 

So if Fischer's Dynamic Authentication Framework resolves to a user that is required to authenticate against a local domain, inside the customer's firewall, then Fischer will communicate with that local domain (Active Directory Server) via the integrated Connected System and leverage the secured GIG communication channel to transport the encrypted credentials to the GIG.  At this point, the GIG will decrypt the credentials and make an authentication request to the Connected System defined within Fischer as the source of authentication for the particular end user attempting to access the application.Fischer’s authentication framework also extends beyond the boundaries of your local network to any defined authentication store, regardless of where it may be geographically located. 

Our Connected Systems course covers the utilization of Fischer’s Global Identity Gateway (the "GIG") which provides the capability to extend authentication and other functionality to end points not on the same network segment, behind a separate firewall, or any other scenario where your Identity ecosystem expands geographically.  Fischer’s Global Authentication Framework can meet all of your authentication needs regardless of the size and type of your organization.

It is important for IGA Administrators to understand that all the de-crypted communications are local and inside the firewall. Furthermore, if desired, IGA Administrators can extend a secure communication channel from the GIG server to the Connected System (where supported by the connected system). This will keep the data encrypted all the way to the Connected System and communication will be secured to/from the GIG and then finally the callback to Fischer's Cloud with a response.