A timeout policy lets you configure granular rules that control authentication and idle connection timeouts.

You can configure timeout policy rules for:

• Authentication Timeout: The time interval used to determine when a user must reauthenticate to access an application.
  • It is only evaluated when a user attempts to access an application. After a user's session has expired for a specific application, the user is only prompted to reauthenticate at the next attempt to access that application.
  • You can define authentication timeout policies for a single application segment or all application segments.

Zscaler Client Connector certificates have a validity of 365 days from the date of enrollment. If the authentication timeout is set to Never, users are only prompted to re-enroll to renew device certificates. To renew device certificates, click Authenticate in the Private Access screen of Zscaler Client Connector. In some cases, the certificate renewal might fail because of connectivity issues to the identity provider (IdP). If this occurs, you might need to log out of Zscaler Client Connector (request a logout password from your administrator if required) and log back in to renew the certificate.

• Idle Connection Timeout: A user's application session idle timeout. An idle connection timeout expiration does not force reauthentication.

For a complete list of ranges and limitations for timeout policy rules, see Ranges & Limitations.

Using Granular Rules for Users and Segment Groups

For each timeout policy rule, you can specify the users and segment groups the rule applies to. This allows you to have different authentication and idle connection timeout settings for different users and segment groups. So even if a user must reauthenticate to continue using an application in one segment group, the user might still be able to continue using an application in another segment group depending on the timeout policy.

In the following configured rules example, the first rule requires users from the Sales department to reauthenticate every two days to continue accessing applications from the Sales App Group. However, the second rule requires the same users to reauthenticate every three days to continue accessing applications from the HR App Group.

See image.

Using the Default Timeout Policy Rule

ZPA provides a default timeout policy rule. The default rule specifies that all users have to authenticate every 7 days for any application, and that their sessions never end due to an idle connection timeout expiration. You can edit the default rule, and it will always apply to all users authenticating from any IdP if you do not configure your own timeout policy rules. So if you've configured some rules that apply to specific users or segment groups, the default rule will still apply to all other remaining users or segment groups from any IdP.

To edit the default rule:

1. Go to Policies > Timeout Policy.
2. Click Default Rule. The Default Rule drawer appears.
3. Click the Edit icon. The Edit Timeout Policy window appears.
4. Edit the default rule, and then click Save.

See image.

The Privileged Remote Access (PRA) Portal and user portal for Browser Access depend on the Default Timeout Policy rule's set authentication timeout.

Viewing User and Application Session Status in Zscaler Client Connector

On the Private Access menu of Zscaler Client Connector, users can find the status for both their user and application sessions.

• The Service Status displays the status of the user session between Zscaler Client Connector and the ZPA Public Service Edge or ZPA Private Service Edge. This status is not impacted by your ZPA timeout policy.
• The Authentication Status reflects whether the user needs to reauthenticate.

See image.

Understanding the Reauthentication Process

When reauthentication is required to use an application, users see a notification on their device:

• Users see a notification similar to the following, which is an example message from the default timeout policy rule.

• If you create additional timeout policy rules, you can set a custom notification message for each, so that users know which application requires reauthentication. The following example is a custom notification message.

Additionally, users see an Authentication Required status on the Private Access menu of Zscaler Client Connector. Users must click Authenticate and log in with their credentials to continue accessing the application.

See image.

The following guidelines apply:

• When a user reauthenticates to continue with an application session, ZPA gets a new SAML assertion. This means that a single reauthentication resets the reauthentication timer for all applications. See an example.

  For example, an organization has a timeout policy that requires reauthentication every three days for the application Payroll, and reauthentication every day for the application Benefits (for both applications, users never have to reauthenticate due to idle time).

  • At 9:00 AM on Monday, Lisa opens the application Payroll.
  • After that application, Lisa does not access any other apps until Thursday at 9:00 AM when she attempts to use Payroll again.
  • She reauthenticates upon being prompted and accesses Payroll.
  • At noon on the same day, Lisa accesses the application Benefits. She has not used this application in over a week, but she is not required to reauthenticate because she reauthenticated three hours ago when attempting to access the application Payroll.

  Close

If your IdP is defined as an application within an application segment, the Authentication Timeout for the IdP application must be set to Never. If an IdP domain overlaps with a domain configured for application discovery, you must bypass the IdP domain in ZPA to avoid user reauthentication failure.

• Because reauthentication settings are defined per segment group and not per individual applications, when a user is active in an application, ZPA considers the user to have been active in all applications that belong to the same group as that application. See an example.

  For example, the applications Sales1 and Sales2 belong to the same application group, SalesApps. A policy is set for the SalesApps group requiring reauthentication after an idle time of one hour.

  • At 9:00 AM, Lanuk begins using Sales1.
  • At 9:30 AM, he stops using Sales1 and begins using another app, Sales2.
  • He works in Sales2 for two hours, until 11:30 AM.
  • Lanuk goes back to Sales1 and can use that app again without reauthenticating, even if he's been technically inactive in that app for over an hour. This is because Sales1 belongs to the same application group as Sales2, and Lanuk has been using Sales2 until now. Activity in one application counts as activity for all other applications in the same application group.

  Close
• The ZPA Public Service Edge uses the notBefore timestamp in the SAML assertion response to calculate if reauthentication is necessary. This needs to be considered when setting up a timeout policy.

See another timeout policy example.

An organization has configured the following timeout policy rules:

• The first rule requires Sales group users to reauthenticate every day to continue accessing applications from the Sales App Group.
• The second rule requires Sales group users to reauthenticate every three days to continue accessing applications from the HR App Group.

With these policy rules:

• At 9:00 AM: Jane, from the Sales group, begins using three applications:
  • BudgetApp from the Sales App Group, where users must reauthenticate every day, or after an idle time of one hour.
  • ComplianceApp from the HR App Group, where users must reauthenticate every three days, or after an idle time of 5 hours.
  • PayrollApp from the Finance App Group, which falls under the default rule where users must reauthenticate every 7 days, but never because of idle time.
• At 11:00 AM:
  • Jane stops using BudgetApp and PayrollApp.
  • She continues using ComplianceApp.
• At 12:30 PM:
  • While actively working in ComplianceApp, Jane opens the BudgetApp again to access some quick data. Upon attempting to use the application, she sees the following dialog, because the app falls under a rule that requires reauthentication after one hour of idle time:

Jane reauthenticates and can access BudgetApp again. With this reauthentication, Jane has reset the reauthentication timer not just for BudgetApp, but also all other applications, including ComplianceApp and PayrollApp. She can access ComplianceApp for another 5 hours without reauthenticating. The PayrollApp is covered by the default rule, so she now has another 7 days before she has to reauthenticate to access that application.

Close

If you need to support reauthentication for application access into ZPA when single sign-on (SSO) is set up using Microsoft Integrated Windows Authentication (IWA) with Kerberos, you must configure the ADFS, LDAP, and KDC applications within an application segment using the proper ports. You also need to configure a timeout policy rule where the Authentication Timeout for these applications is set to Never. To learn more, see Supporting Reauthentication into ZPA via Microsoft IWA with Kerberos.

About the Timeout Policy Page

On the Timeout Policy page (Policy > Timeout Policy), you can do the following:

1. View a list of applied filters available from the current and previous user sessions. Applied filters must be saved to the user session first before they can be viewed. Use the drop-down menu to select the applied filters to view. To learn more, see Using Tables.
2. Hide the filters on the page by clicking Hide Filters. Click Show Filters to display the filters.
3. Refresh the Timeout Policy page to reflect the most current information.

4. Click the Settings icon () to open the Terminate All Sessions drawer. In the Terminate All Sessions drawer, you can enable or disable termination of all running application sessions upon timeout according to the timeout policy or access policy action.

   The option to enable or disable termination of all running application sessions upon timeout is available only for existing tenants. This option is hidden and automatically enabled for tenants created after November 3, 2022.

5. Filter the information that appears in the table. By default, no filters are applied.
6. Add a new timeout policy rule.
7. Edit the Default Rule. To learn more, see Default Timeout Policy Rule.
8. Expand all the displayed rows in the table to see more information about each policy rule.

By default, the UI displays the first 100 rules. Alternatively, you can scroll to see more rules.

9. View a list of all timeout policy rules that were configured. For each rule, you can see:
   • Rule Order: The policy evaluation order number for the rule. ZPA applies policy rules based on the order they are listed here. To change the rule order, click on the number and manually enter a new value.
   • Name: The name of the rule. The description is also displayed, if available.
   • Status: The status of the rule (Enabled or Disabled).
   • Timeouts: Indicates the specified authentication and idle connection timeout intervals. When the row is expanded, it provides a visual representation of the Criteria (e.g., SAML attributes per IdP, segment groups, etc.) and Boolean logic used within the rule.
10. Copy an existing timeout policy rule's criteria, and use it to create a new rule.
11. Edit an existing timeout policy rule.
12. Delete a timeout policy rule.
13. Modify the columns displayed in the table.
14. Display more rows or a different page of the table.
15. Depending on your ZPA Admin Portal subscriptions, you will see the following ZPA policy options:
    • Access Policy
    • Client Forwarding Policy
    • Isolation Policy
    • Privileged Policy
    • Security Policy
    • Redirection Policy