Fischer offers its own MFA application as a part of the product suite. The application supports up to 5 factors of identity verification. Leveraging Fischer's application can streamline your IGA solution and remove other vendors that may be managing your MFA as a point solution. Leveraging Fischer's built in Authenticator can consolidate your IGA stack and streamline the experience for your end users.
How to obtain the App
Fischer has built in multi-factor authentication and mobile authentication within it's product suite. This component releases organizations from the burden of managing a separate security component, with yet another vendor involved. Fischer's Authenticator is available in the Apple Apps Store and the Google Play store. Search for "Fischer Identity" or "Fischer Authenticator" and you will find the application available in the store for free download.
Device Registration
Multiple devices can be registered against a single identity. Depending on the authentication configuration employed by an organization there are a few variations to the registration workflow. The device registration processes are defined below:
Device Registration w/ no other Identity Verification Features Configured
In this scenario, Fischer would be configured with no other Identity verification factors in front of the device registration process. This can occur if an organization is employing password-less authentication and is not leveraging attribute based verification and/or username/password verification in lieu of secret questions.
Note that an authorized email address is required during device registration in this specific scenario:
Registering a device is performed via the the generation of a unique QR Code and associated code. This provides Identities with the ability to leverage QR code scanning (which is embedded into the Authenticator app, or they can manually type in the generated code. For scenarios where no other form of Identity verification has occurred, the QR Code will be delivered to the authorized email address on file. During the initial on boarding of the user, this may be a secondary (personal) email address since in most cases the Identity does not yet have access to the organization's email system. Configuring the device registration workflow to function, there is a global setting embedded within Fischer that will need to be set so delivery of the QR code can occur. This will be discussed in the below "Global Mobile Authentication Configuration" section.
Device Registration with defined first factors (attribute resolution, secret questions or authenticating with a known system username and password)
In this scenario, Fischer will automatically detect that a first factor of Identity verification has been employed and it will display the QR Code on the user interface where the Identity is on boarding. This functionality will work specifically when the Authenticator is configured as the secondary authentication factor and Fischer recognizes that a device is not yet registered.
Administrative Device Registration
Fischer also provides the ability for IGA Administrators to initiate the device registration process from the admin UI. Specifically from the "Modify Profile" interface. The Identity must have a valid email address stored against their Identity profile and/or mobile phone number. The attributes required to perform administrative device registration will vary based on the global configuration options (outlined below) and how the organization is allowing users to receive their QR Code.
Registering a Device from Self-Service
Fischer provides the ability for IGA Administrators to set multi-factor as optional. This is for cases where the Identity may not have their device with them the first time they login. Instead, enabling optional will still allow the Identity to authenticate via their defined first factor and they will be prompted that they qualify for multi-factor. IGA Administrators have the option to enable device management for Identities. This feature will appear as a tab within self-service. By default the tab label will say "Manage Security". Once a user accesses this tab from self-service, they will have the option to add their device from the authenticated self-service session. This provides ease of use for end users as well as eliminating administrative intervention (or a help desk call) if the user is forced to register their device before authenticating and rather setup their device a later time when they have their device available. The user will click "Activate Device" if they decide they want to register their device within their authenticated self-service session. At that point, the next time the user authenticates they will be prompted with a PUSH message to their device and MFA will be configured.
Available Features of Fischer's Authenticator
The mobile feature provides organizations with many options and configurations to meet the needs of your IGA Program and End Users. The following table outlines the features available when you deploy Fischer's Authenticator:
| Primary (Password-less) Authentication & Identity Verification | |
|
Fischer Identity supports password-less authentication for its Self-Service Portal. This feature is enabled by the use of Fischer's (Mobile) Authenticator app. Password-less authentication is truly the next-generation of authentication technology and it is available now within Fischer. As password breaches continue to increase, the need for passwords to be obfuscated altogether will surface more and more. Organization's that leverage password-less authentication can completely mask and hide, and scramble all passwords to target systems (when SSO is enabled) offering the ultimate security and mobility. This approach would enable zero-human-interaction with generating and/or provisioning passwords to Connected Systems (including Fischer's Software as well). In this model, no one will ever know what the actual password is, rather rely on their mobile device for identity verification and authentication to Fischer's Self-Service Portal. This is by far the most user-friendly, advanced approach to a secure, mobile-friendly experience for end users. As security advances and hackers get more and more sophisticated, the focus on the password will become more on the highest entropy possible, to secure the native account while offering an acceptable amount of defense in depth, related the number of factors an application should consider before trusting the inbound request. Features such as proximity-based authentication, adaptive access (geo-fencing) and other inherence factors help organization's to govern access to applications while simultaneously providing end users with the empowering of self-serviced driven mobile authentication. Fischer Identity supports password-less authentication for its Self-Service Portal. This was strategic as it provides end users with the ease of authentication (they don't have to know know any password whatsoever) at their fingertips while providing organizations with a method to remove passwords altogether when accessing Fischer's Self-Service Portal. |
|
| Multi-factor Authentication | |
| Alongside the ability to eliminate the password via Fischer's Authenticator, organizations can leverage the Authenticator as a secondary factor of authentication. Fischer provides username/password and attribute resolution as primary factors of authentication which can be used in conjunction with the Authenticator to send a push message to authenticating Identities to provide 2-factor authentication to its user population. | |
| Adaptive Access Control | |
|
Within Fischer's Authenticator is an option to enable location-based authentication and authorization. This feature provides organizations with the ability to build geo-fences around their Fischer Identity portal so end users are locked out of authenticating unless they are physically in an authorized geo-location. Geo-fencing is the industry term to describe this functionality and Fischer offers it in two ways.
|
|
| Policy-based Access Control | |
| Fischer further enhances authentication and authorization by offering policy-based access control. Fischer provides IGA Administrators with the ability to define policy-based access. This feature empowers IGA Administrators to configure different authentication factors and requirements dependent up the Identity type. For example, for executives that travel, the defined geo-fence may be larger or have more triangulated locations that allow executive Identities to move freely and do business but in a controlled, secured manner. Defining a second authentication policy for an end user who should ever only be accessing the application from the corporate headquarters is provided by building distinct authentication policies. Policy-based access control employed within conjucntion with adaptive access control provides organizations with an advanced level of risk control. | |
| PUSH-based Authentication | |
| The Fischer Authenticator leverages PUSH technology, eliminating the SMS from the authentication and Identity verification process in alignment with the NIST deprecation of SMS as a secure transport protocol for the delivery of any information related to authentication. | |
| Knowledge Based Authentication | |
| Fischer provides the following knowledge-based authentication factors within Authenticator: (1) Circle Code (2) PIN Code | |
| Inherence Based Authentication | |
| Fischer provides the following inherence-based authentication factors within Authenticator: (1) Geo-fencing (2) bio-metric (where supported by the smart phone) | |
| Possession Based Authentication | |
| Fischer provides the following possession-based authentication factors: (1) Bluetooth proximity |
Global Mobile Authentication Configuration Settings
The global configuration is accessible within the administrative user interface. Once you've authenticated to the admin UI, go to "Configuration→Configuration (Function Menu)→Select "Mobile Authentication" from the combo box.
Fischer provides global configuration options when configuring mobile authentication, specifically for the Fischer Authenticator. This section will outline the global settings to be configured prior to leveraging mobile authentication.
| Integration Secret Key - Admin UI | |||||||||||||||||
|
In order to secure the communication between your administration user interface and the Fischer Authenticator, you must obtain an integration key from Fischer. Contact your Implementation or Solution Management Lead to request the key. To obtain the key, you must provide the URL to your (Fischer) administrative user interface.
It is important to note that Fischer's Authenticator service is cloud based. So in order to enable it for some features that may be more protected than others, for example the administration UI URL. If IGA Administrators want to leverage Fischer's Authenticator as a second factor of authentication for the administration interface, this means Fischer's Identity Server must be configured to allow traffic to an external (public) API to send the integration secret to the Authenticator service and also be able to receive a call back once Authenticator has verified the user to allow the user to then access the interface.
|
|||||||||||||||||
| Integration Secret Key - IdP | |||||||||||||||||
| In order to secure the communication between your IdP login screen and the Fischer Authenticator, you must obtain an integration key from Fischer. Contact your Implementation or Solution Management Lead to request the key. To obtain the key, you must provide the URL to your (Fischer) IdP login screen. | |||||||||||||||||
| Integration Secret Key - Self-Service | |||||||||||||||||
| In order to secure the communication between Self-Service and the Fischer Authenticator, you must obtain an integration key from Fischer. Contact your Implementation or Solution Management Lead to request the key. To obtain the key, you must provide the URL to your (Fischer) self-service interface. | |||||||||||||||||
| Integration Secret Key - Studio | |||||||||||||||||
| In order to secure the communication between your Workflow Studio and the Fischer Authenticator, you must obtain an integration key from Fischer. Contact your Implementation or Solution Management Lead to request the key. To obtain the key, you must provide the URL to your (Fischer) Studio. | |||||||||||||||||
| Mobile Authentication Server - Timeout | |||||||||||||||||
| This timeout setting controls how long the Authenticator request will wait for the user to authenticate via their mobile device. | |||||||||||||||||
| Mobile Authentication Server - Verify Server SSL | |||||||||||||||||
|
This value should always be set to True. The Identity server will verify the SSL certificate of the Mobile Authentication sever (i.e. The Identity Sever). Note the signing cannot be private or the session request will be rejected by the Authenticator service. A public CA must be used for signing the certificate. |
|||||||||||||||||
| Registration QR Code E-mail Notification | |||||||||||||||||
|
This function provides for the setting of the email notification that will be sent to the Identity during a QR Code registration event. The QR Code will be sent to the email address specified within the mobile configuration. While Fischer does archive all notifications sent to Identities, we have taken the necessary steps to block the display of the QR Code in our archives so that it cannot be seen or potentially used to link a device by an IGA Administrator or a delegated administrator viewing notifications sent via the Self-Service Client Administration feature. |
|||||||||||||||||
| Registration QR Code Notification Email Attribute | |||||||||||||||||
|
This function provides IGA Administrators with the ability to set the attribute/value pair stored within Fischer's Identity Registry that will be used to communicate with the end user when a QR Code must be sent via email.
Primary Email Address vs. Secondary Email Address
Fischer provides for the storage of multiple email addresses. When configuring the mobile authentication, IGA Administrators must take into account that the on boarding Identity most likely will not have access to their organization's email account at this point (since they are on boarding and have not set their password for their accounts at this point). It is a best practice to ensure that a secondary, authorized email address (most often it will be the Identity's private or personal email address) is configured as the email used for sending the QR Code for device registration.
If the primary (organization) email attribute is used, the user will not be able to on board unless Authenticator is used exclusively as a second factor of authentication and not as an Identity verification method. If Fischer's Authenticator is used as the primary method of Identity verification and IGA Administrators have set MFA to optional for users, they will be able to bypass device registration and authenticate using the first factor.
|
|||||||||||||||||
| Registration QR Code Notification Method | |||||||||||||||||
|
This function provides IGA Administrators with the ability to configure the delivery method of the QR Code. The available options are as follows:
|
|||||||||||||||||
| Registration QR Code SMS Notification | |||||||||||||||||
| This function provides IGA Administrators to customize the text to be sent via SMS to a registering Identity. |