How To: Increase the Allowed Clock Skew for API Calls

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: All

     

    Overview

    The SecureAuth API has a default maximum allowed clock skew of 60 seconds between the server making the call and the Identity Provider (IdP) server. We recommend leaving this default in place and using Network Time Protocol (NTP) to keep server clocks in sync. This article explains how to increase the allowed clock skew for the exceptional cases where NTP is not possible and the clocks cannot otherwise be corrected.

    1. Take a backup of the current web.config for the realm in question.
    2. In the Admin Console, go to Advanced Settings.
    3. Click Tools | Decrypt Web.Config, and decrypt the realm.
    4. Open the web.config in a text editor. The default path is D:\SecureAuth\SecureAuth<realm number>\Web.config.
    5. Search for an Api.HttpRequestValidityPeriodInMinutes key in the <appSettings> section. If it already exists, note its current value.
    6. Add or update the setting in the <appSettings> section, setting the value to the number of minutes of clock skew to allow. 5 minutes is a realistic maximum:
      <add key="Api.HttpRequestValidityPeriodInMinutes" value="5" />
      The web.config appSettings section with the Api.HttpRequestValidityPeriodInMinutes key added just before the closing appSettings tag.
    7. Save the web.config.



     

    Special Considerations

    We recommend leaving the default 60-second clock skew in place and using NTP to keep server clocks synchronized. Only increase this value when NTP cannot be used and the clock drift cannot otherwise be corrected — increasing it beyond a few minutes reduces the security benefit of this check.


     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.