Authentication (Overview)

Fischer provides a robust and granular authentication framework.  While organizations can leverage native, LDAP authentication capabilities many choose to abstract authentication to introduce other protocols including SAML, ADFS or CAS in order to localize authentication inside the firewall.  This abstraction approach is largely used for cloud based deployments but can also be leveraged for on premise deployments as well.  

Fischer currently supports the following authentication protocols for end user / administrative authentication:

Enterprise / Cloud Authentication Protocol Support

Mobile Authentication Support

Fischer currently supports the following mobile authentication protocols

Social Authentication

Fischer currently supports the following social authentication mechanisms

The "Identity System" for Authentication

Fischer’s native authentication protocol is LDAP.  During the installation of the product, you are asked to provide an LDAP directory that Fischer’s product can bind to. This LDAP system is called the “Identity System” and serves as the native authentication mechanism for the Fischer product.  A single LDAP user must exist within the LDAP system that Fischer’s installed can use as the “master admin”.  This LDAP object must be present because the installation will require the credentials, including the distinguished name (“dn”) of the master admin.  This master admin account will be the only user that is able to authenticate to the Fischer product once the product is up and running and available for access.  If it is desired to utilize the Identity System as the primary source of authentication for all Identities, it is important to ensure that your underlying LDAP BaseDN structure is represented properly within the Identity System configuration.

Federated Configurations

The “Identity System” is also used for building SAML assertions when Fischer’s Identity Provider (IdP) is configured as the trusted authentication source.  The IdP users the “Identity System” to retrieve the necessary attributes to build SAML assertions. This is for Virtual IdP (cloud) solutions only.

Global Authentication Properties

This setting is found under the “Configuration” tab and the “Configuration” Function Menu:Fischer offers further authentication options to help craft your end user experience while simultaneously ensuring that you are able to govern, enforce and control how your users will operate within your secured IGA ecosystem.  The following global settings are accessible from the "Configuration" tab.

There are multiple locations you can access to configure key global authentication parameters that will affect the user population.  They are spread out among various configuration menus.

Maximum Failed Login Attempts

This setting is rather self-explanatory but it applies globally to all authentication attempts against any product authentication configuration where users may mis-type their credentials or maybe have forgotten their userid and/or password.

Specifying the User ID Attribute(s)

Fischer provides organizations with the option to specify which value they will allow their end users to user when authenticating.  Some organizations want to allow users to use their email address to login, while others use a single NetID (or SSO ID), while others may want display name, etc.  Fischer has no preference pertaining to which attribute is used to authenticate, the only requirement from Fischer is that the stored value in the attribute must be unique to the end user.  For obvious reasons if the same value is stored against multiple identities, our product will not allow authentication to occur.  The option to set the primary user ID attribute to use is found here:

The combo box presented will list various attributes IGA Administrators can select.  The attributes in the list will be Fischer's Provisioning Hub Schema which is the proprietary Fischer schema used to normalize identity metadata into a extensible schema that is used throughout the product.  You can learn about the Provisioning Hub Schema here.

IGA Administrators can select one of the following attributes to be used as the Primary User ID Attribute for authentication to the product:

Fischer further extends a organization's ability to create an elegant and extensible end user experience by offering a configuration property that if set provides end users with the ability to user two different values as their username when authenticating to Fischer.  For example, a customer may want to use the sAMAccountName from Active Directory and also allow the end user to type in their email address.  This allows users to have a preference and creates less opportunities for users to forget their user name which would lead to a help desk call.

By default, the User ID Attribute - Secondary  is not enabled.  IGA Administrators must deliberately select an attribute to use.  The list of available attributes is the same as the primary User ID attribute.  Defer to the image above showing the available attributes in the combo box.