Roaming authentication allows users to authenticate from another device that has the authenticator installed and a valid credential on it. There are three main use cases for roaming authentication:
- Enable roaming authentication for everybody in the tenant. For this use case, This use case allows everyone in the tenant to be able to use roaming authentication.
- Gate access to roaming authentication by groups and specific IP ranges. The main use case for this is that you don't want everyone to be able to use roaming authentication as it is a less secure authentication method, so you can restrict it to certain IPs, IP ranges, and user groups.
- Another use case might be kiosks or shared desktops that don't have a users' Beyond Identity credential on them. If they have a Beyond Identity credential on their phone, they could gain access in this scenario to the desktop.
Each tenant has a roaming authentication configuration that applies to all authentication flows for that tenant’s users (OIDC, SAML, and WS-Fed).
Roaming authentication can also be configured in policy, which has the final say (because it will ultimately allow or deny the authentication). Roaming authentication must be both enabled and allowed by policy (because it will ultimately allow or deny the authentication) for successful authentication.
To configure roaming authentication
- Go to Settings > Tenant in the console and scroll down to Authentication Options.
- Click the Edit icon and enable Roaming Authentication.
- Modify the following as needed:
Option Description IP Include List This option checks the “remote IP” of the user agent against allowed IPs.
- All IPs (the default)
-
Specified IP lists - References one or more named IP address lists.
Note: Named IP address lists are recommended because they can more easily be kept in sync with policy rules that reference the same attribute lists. - Specified IP address - Specify inline IP addresses. The maximum number of user groups allowed is 10. If you need more than 10, consider using an IP address list.
If you select any option other than All IPs, roaming authentication will only be offered to users who begin their authentication from a valid IP address.
IP addresses can be specified as:
- A single IP address (e.g. 192.168.0.3 or 2001:db8::68)
- IPv4 and IPv6 are both accepted for any of these values.
- A Classless Inter-domain Routing (CIDR) block (e.g. 192.0.2.0/24 or 2001:db8::/32)
- CIDR blocks define an IP address and prefix length, as defined in RFC 4632 and RFC 4291.
- An IP range (e.g. 192.168.0.1-192.168.0.5)
- Ranges are defined as two IP addresses separated by a single '-' character.
- Ranges are inclusive.
- IP addresses in the same range must use the same IPv4 or IPv6 format.
- The first IP address in the range must have a smaller value than the second IP address in the range.
User Group Include List This option guesses the username before authenticating and checks that the user is in an allowed group.
- All user groups (the default)
- Select user groups - Select one or more user groups from the list. The maximum number of user groups allowed is 10.
Because this decision is made before authentication, determining the groups that a user belongs to is an approximation. This is based on optional “login hints” that may be provided during authentication:
- login_hint parameter provided in OIDC or WS-Fed requests
- username parameter provided in WS-Fed requests
Note: “Login hint” refers to either of these parameters because they both provide a “hint” for us to determine which user is attempting to login.
WS-Fed supports both of these parameters, and it's possible that they are both provided in the same authentication request and contain different values. If different values are provided in a single request, each login hint will be used to search the directory and roaming authentication will be offered if either returns a user that belongs to one of the specified groups.
The following search is performed in the tenant’s directory if this configuration is used and a “login hint” is provided:
- email address that matches the login hint (case insensitive)
- email address where the "local" part matches the login hint (i.e. login.hint matches login.hint@example.com or login.hint@foo.bar)
- user name matches the login hint (case insensitive)
If no user is returned from this search, or more than one user is returned, the authentication request is handled as an “unknown user.” This means that if, for example, there are multiple users in the directory with the same user name or email address, the login hint will be ambiguous and roaming authentication will not be offered.
If neither “login hint” parameter is provided in a given authentication request, the user is always treated as “unknown,” and therefore can’t belong to any of the specified groups. These parameters exist only in OIDC or WS-Fed, so all SAML authentication requests are handled as an “unknown user.”
Note: This feature can add some additional latency to authentication requests (because of the searching required) so it should be avoided by tenants that have very strict latency requirements during authentication.
Note: Allowed IP addresses and allowed user groups can be set independently. If both are selected, logic will be combined using AND (i.e. the IP address AND the user group must be “allowed” for Beyond Identity to offer roaming authentication).
- Click Save Changes. The authenticator will display the following additional features for users during authentication:
- A QR code during authentication. The code can be scanned on another device that has the authenticator and a valid credential on it to authenticate.
Note that Linux doesn't support scanning the QR code but it will display it in the browser. - An extra confirmation popup to confirm verification from the user.
Windows example:
macOS example popup:
- A QR code during authentication. The code can be scanned on another device that has the authenticator and a valid credential on it to authenticate.
- Make sure you review policy rules that include authentication transactions because they may also impact the roaming authentication method.
Comments
0 comments
Please sign in to leave a comment.