Overview of Adaptive Multi-Factor Authentication
Multi-factor authentication (MFA) is a well-known security practice that requires users to pair something they know with something they possess before gaining access to their accounts and other types of sensitive information. MFA helps to safeguard against threats arising from compromised credentials. EmpowerID recognizes this and has implemented an Adaptive MFA engine that provides an extra layer of security for all types of authentication, including Web SSO, LDAP, and RADIUS. EmpowerID's MFA is "adaptive" in that it can be configured to analyze contextual information such as IP addresses, identity providers, devices, distance traveled, and velocity since the last login, and other real-time factors to dynamically assess the risk of each login. A strong second factor can be required before access is granted if a risk is identified. These factors, known in EmpowerID as "MFA methods" or "MFA Types," include many popular factors in use today, like DUO Push, YubiKeys, and one-time passwords delivered to a person's favorite communication medium.
In addition to Adaptive Authentication, which can deny login or require Multi-factor authentication, EmpowerID includes standard MFA policies. In EmpowerID, MFA is a flexible, points-based, or Level of Assurance (LoA) system that is easy to configure. Administrators define a specific number of points, known as "trust or MFA points or LoA," and apply those points to Password Manager policies, MFA methods, IP address ranges, identity providers, and other objects in EmpowerID to provide a target point number for authenticating to EmpowerID, as well as for accessing any third-party applications secured by EmpowerID. Depending on how EmpowerID is configured, users may be required to pass through several checkpoints and submit additional biographic information before gaining access to resources. Checkpoints can include the user's IP address, the selected identity provider, and the Password Manager policy assigned to the user.
From a high level, the below image shows what a typical standard MFA scenario could look like. In the scenario, there are three possible outcomes based on the combination of a configured IP Address Range of blacklisted IP addresses and Password Manager policies:
EmpowerID denies access to the Login page to devices with IP addresses that fall within the blacklisted IP Address Range. In step one, three devices browse to the Login page. The IP Address checkpoint denies the mobile phone access because its IP address is blacklisted.
EmpowerID grants devices with non-blacklisted IPs access to the login page. In step two, these devices include laptops and tablets. The users with these devices select one of the identity provider options available to them and submit their credentials. EmpowerID adds any trust points set for those identity providers to the user.
EmpowerID checks the Password Manager policy assigned to each user and, based on the MFA settings of that policy, authenticates them or directs the user to perform further identity proofing by selecting an available MFA method. In the above scenario, the user with the laptop does not need further proof of their identity, while the user with the tablet does. After the user with the tablet meets the requirements of their Password Manager policy, the user is authenticated, and EmpowerID grants them access.
In the above scenario, users encounter three checkpoints: the IP Address checkpoint, the Identity Provider checkpoint, and the Password Manager policy checkpoint. Each is discussed in greater detail below.
IP Address Checkpoint
One component of EmpowerID's Adaptive MFA engine is the IP Address checkpoint. This checkpoint is the initial gate through which users must pass before gaining access to the EmpowerID Login page. IP Address checkpoints comprise special objects you create, known as IP Address Ranges. IP Address Ranges allow you to define the login options available to users accessing your portal from any device that falls within the specified IP address range. EmpowerID provides three IP address range types that you can configure. These include the Internal, External, and Blacklisted ranges. When you create an IP address range, you choose the type and specify the beginning and ending IP addresses for that range. Once you create the IP address range, you can apply it to your Password Manager policies and any federated applications you may use. Usage examples could include:
Configuring the login policy settings of a Password Manager policy to require users to accumulate a specific number of Multi-factor authentication trust points to access their accounts based on their IP address. You could require internal network users to accumulate one trust point, while users outside your network might need to acquire two or more points.
You could create an Internal IP address range for your network users and allow them to log in using Windows authentication only.
If you have partner organizations using the EmpowerID Remote Windows Identity Provider to authenticate against your domain, you could create an IP address range for the public IPs of each of those partners, allowing them to log in using the Remote Windows IdP only.
You could create an External IP address range for users outside your network and give those users the option to authenticate using EmpowerID forms auth, one or more trusted social media applications, or a combination of both EmpowerID forms auth and social media logins.
You could create a range of known blacklisted IP addresses to deny users with those addresses from accessing your environment.
If you do not create any IP address ranges, EmpowerID treats all login attempts as originating from outside your network (external logins). This is important to note if your login policy requires multi-factor authentication and you have set the number of trust points differently for internal versus external users. In this case, EmpowerID would consider your network users to be external and require them to accumulate the trust points you set for external users. See Creating IP Address Ranges for more information.
Identity Provider Checkpoint
Another component of EmpowerID's Adaptive MFA engine is the Identity Provider checkpoint. The login page is the second gate users must pass before accessing EmpowerID. The Identity Provider checkpoint is a selection of SSO connections you can create for third-party identity provider applications that support using OAuth 2 for identity transactions. This allows you to offer users the ability to authenticate to EmpowerID using the credentials from any OAuth Consumer application in which you establish a trust relationship. EmpowerID provides a number of templates configured out of the box for use with popular OAuth consumer applications like those listed below. In addition, EmpowerID provides a generic template that you can use as a starting point for building custom connections.
ADFS (Active Directory Federation Services)
Azure
Box
EmpowerID OAuth
EmpowerID Mobile OAuth
Facebook
Github
Google
LinkedIn
Microsoft Live
Paypal
Salesforce
SmartCard
Twitter
Windows Auth
Yahoo
Yammer
You can assign an MFA type for each application so that it gets the trust point value for that authentication type. For more information, see Assigning MFA Types to Applications. EmpowerID adds trust points for the Identity Provider to the tally and passes them along to the password manager policy.
Password Manager Policy Checkpoint
The final checkpoint is the Password Manager Policy. The policy defines login restrictions, password complexity requirements, self-service password reset options, and enrollment requirements that govern users' ability to manage their passwords or log in to EmpowerID or any application using EmpowerID for login protection. You can create custom policies or use the default Password Manager Policy that is applied to the entire enterprise. The Authentication Settings in each policy define the number of MFA points required to log in from local or remote subnets. Depending on the MFA points required, the user may be authenticated or sent for further authentication. For more information, see Setting Up Password Manager Policies and Assigning Adaptive Authentication Rules to Password Manager Policies.
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591159
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591306
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591387
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591524
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591584
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591659
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591724
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591789
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591864
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390591944
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592039
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592099
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592154
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592221
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592287
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592349
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592414
https://dotnetworkflow.jira.com/wiki/spaces/EAGV24R2/pages/3390592539