The Global Authentication Framework |
---|
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
LDAP (v3) | ||
LDAP is the default authentication protocol for the Fischer product. If left unchanged, all interfaces requiring credentials will utilize the LDAP directory specified when the product was installed. The Connected System in Fischer used for native authentication is called "The Identity System". | ||
SAML (2.0) | ||
This protocol is supported for authenticating to the Self-Service Portal and Fischer's Identity Provider | ||
CAS | ||
This protocol is supported for authenticating to the Self-Service Portal and Fischer's Identity Provider | ||
ADFS | ||
This protocol is supported for authenticating to the Self-Service Portal and Fischer's Identity Provider | ||
Mobile Authentication Support
Fischer currently supports the following mobile authentication protocols
PUSH | |
This protocol is supported for authenticating to the Self-Service Portal, IdP, Workflow & Connectivity Studio and Administration UI | |
SMS | |
This protocol is supported for authenticating to the Self-Service Portal, PIN Reset, Kiosk and Administration UI | |
TOTP | |
This protocol is supported for authenticating to the Self-Service Portal, PIN Reset, Kiosk and Administration UI |
Social Authentication
Fischer currently supports the following social authentication mechanisms
This protocol is supported for authenticating to the Self-Service Portal. It is important to note that Facebook can be used as a primary form of authentication, essentially serving as the Identity Provider for accessing Fischer's Self-Service Portal. |
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.