An app policy is an application security policy which allows you to define the security requirements for a specific app. With an app policy, admins can require multi-factor authentication, specify whitelisted IP addresses, and more.

To set up an app policy that fits your needs, you have several options:

• Add a multi-factor authentication (MFA) requirement to authenticate login for specific apps
• Bypass MFA if the user has previously authenticated within a defined number of minutes in their session 
• Restrict the IP addresses that can access the app
• Name specific IP addresses that can bypass MFA, if MFA is required for the app

By allowing specific apps to have their own MFA policies, you can remove the MFA requirement from individual user policies while still maintaining strong authentication for the applications that require it. Restricting app access to particular IP addresses prevents users from accessing the app from outside your firewall, regardless of their user-based security policy.

You can apply an app policy to an app and apply a role-based app policy for users in a particular role. If users authenticate from a known and trusted IP address, admins can configure the policy to bypass MFA requirements for that address. 

Create an app policy

1. Go to Security > Policies and click the New App Policy button.

2. On the Settings page, name the policy and select your policy options.

   

   IP Address Whitelist:  Enter a list of IP addresses, separated by spaces, that can access the apps associated with this policy.

   Smart Access: Deny access if user meets or exceeds the selected risk level.

   
   

   • Low: Low risk tolerance, extremely strict security standards. MFA is more than likely required when users log in.

   • Medium: Medium risk tolerance, but strict security standards. Your org accepts a medium risk level when users log in. MFA prompts decrease when a user exhibits predictable and secure behavior, such as logging in from the same location every day at the same time.

   • High: High risk tolerance, higher level of risk in exchange for an easier user experience. Doesn't usually require MFA, but presents MFA challenges at appropriate times, such as unusual login locations.

     For more information about Smart Access, watch the video below.

   Forced Authentication: Select the checkbox to force a user to re-authenticate, with or without MFA. Users will see a login dialog prompt before being allowed to access a sensitive app even if the user has a valid, non-expired session.

   The Users must authenticate after provides the capacity to enable a configurable grace period. This allows you to set the amount of time between the start of a user's session and a re-authentication request from the app. The user is prompted to provide credentials if they attempt to create a session in the app that exceeds the grace period. For example, if they authenticate with OneLogin within 5 seconds, and the grace period is 15 seconds, then the user isn't prompted to re-authenticate. The available grace period values are: 3, 15, 30, 60 seconds. The default value is 60 seconds.

   Note: We set a 3 second minimum because users will experience a re-authentication loop if the grace period is less than 3 seconds.

   Require Trusted Device: If you click Enabled, 3rd Party Certificates Enabled appears. In Select Certificates for Validation, search for your 3rd party cert. Allows you to leverage extant PKI infrastructure to require 3rd party certificates as a 2nd authentication factor. End users can access the app if this cert is installed on the device.

   Note: Please contact your account manager if you want to enable 3rd Party Certs for your org.

   To learn more about configuring 3rd Party Certificates, see 3rd Party Certificates.

   Multi-Factor: Select the checkbox to require MFA verification for this app policy. You can select an authentication factors that a user must complete in order to access an application. This setting can be used to increase security for sensitive apps. For example, an org wants to add an additional level of security to access ADP by requiring OneLogin Protect as an auth factor.

   The available authenticators are based on the user policy assigned to the user.

   Note: If you select more than one factor, the end user needs to complete one of the required factors. If the end user completed one of the required factors as part or the user policy (authenticated into the portal), then they don't need to complete the same factor to access the app.

   Bypass MFA for the following addresses: Enter a list of IP addresses that can bypass MFA requirements to access the apps associated with the policy. 

   Skip if OTP received within last X minutes: Ask for OTP only if the user hasn't already entered one within the number of minutes you select from the dropdown (when accessing OneLogin to sign into another app, for example).

   Note: OneLogin can match Duo users based on their email address. Up until this release, users were matched based on an encoded version of their email. For example, an email address O'Brien@example.com was previously linked as O%27Brien in Duo.

   Now, users can be linked using the decoded value O'Brien@example.com. All OneLogin users will continue to be matched based on the encoded value to minimize disruptions.

   To enable Duo linking based on decoded ' and & characters, please contact OneLogin Support. We will further enable this functionality in the future.

Apply an app policy

1. To apply an app policy to all users, go to Applications > Applications > and select an app. 

2. Click the Access tab and in the Policy section, select the appropriate policy.

3. Click Save. The app is now subject to the security policy.  

Add a role-based policy

Instead of applying the same policy to all users of an app, you can specify an alternate policy for a specific role. For example, you can require certain users to provide OTP verification for the app while letting other users sign in with only a user ID and password.  

1. Go to Applications > Applications and select an app. On the Access tab, in the Role-Based Policy section, click Add Role-Specific Policy. 

2. Under Role-Based Policy, select a role and the policy to apply to the role from the dropdown.

   The role must be enabled for the app. You can enable it by clicking the role name under Roles.  

   

3. Click Save.

   Now the users in the selected role will have the access requirements specified by the application security policy you applied to the role, and the users in the other roles with access to the app will have the policy that you enabled under Policy.