How to create Adaptive Authentication policies efficiently for improving instance performanceSummaryProblem Statement Adaptive Authentication policies filters and conditions can be formed in various ways where all of the possible combinations would have the same end result but could be different wrt performances. Policies that are formed with many filters exceeding the cache size will fetch the policy inputs from DB instead of the cache for every policy execution in the Pre-Authentication* use case, resulting in DB queries which could cause efficiency and performance issues. Pre-Authentication * - Pre Authentication Policies are executed for incoming requests to the server. Not being careful while crafting Pre-Authentication policies could result in performance implications causing various DB queries on the instance for every call. Suggestions Here are the suggestions for crafting the Adaptive Authentication policies. Policies should be crafted efficiently keeping IP filter criteria, and IP address collections as minimal as possible covering all the business use cases. Use IP Ranges and subnets wherever possible and adjust them in a few criteria. It is not effective to loosely spread IP ranges in multiple criteria.Policy conditions should be crafted by aggregating multiple filter conditions under policy conditions to reduce the number of conditions created. It is not necessary to create separate policy conditions for every filter. Refer example in the Examples section.There are different contexts where policies are executed. Some policies are executed with every inbound call like the Pre-Authentication Policy, and some during login flow like Post-Authentication etc. Each of the contexts could be optimised separately.Pre-authentication policies are executed with every call to the server and either allow or deny the request based on policy result. As this is called with every call, very few filter criteria with IP ranges should be configured to optimise performance.Verify Policy cache size on the instance before creating IP filters. As part of Xanadu release, each filter criteria has its own system properties. Details are updated at the end of article. Examples IP filter criteria Policy Filter The below images show two different ways to configure IP filter criteria The first one with separate ranges in two different Filter criteria and both are linked to policy. The second one with both the ranges in the same filter criteria, will achieve the same results as the first but with less filter criteria record and is more efficient than the first one. First Scenario Second Scenario (Better Approach) Policy Conditions The below images show two different ways to configure Policy conditions The first one with separate conditions for two different Filter criteria and both are linked to policy. The second one with both the filter criteria in the same policy condition, will achieve the same results as the first but with fewer policy conditions and more efficient than the first one. First Case Second Case (Better Approach) Different cache properties and its default sizes: Filter Criteria cache System property Default size IP filter glide.authenticate.ip.filter.cache_size 300 Generic system filter glide.authenticate.generic.system.filter.cache_size 15 Generic user filter glide.authenticate.generic.user.filter.cache_size 15 Geo Location filter glide.authenticate.location.filter.cache_size 50 Group filter glide.authenticate.group.filter.cache_size 15 Role filter glide.authenticate.role.filter.cache_size 15 IP System property Default size Max size IP Address range glide.authenticate.ip.address.cache_size 10,000 30,000 IP Subnet range glide.authenticate.ip.subnet.cache_size 400 1200 Also limited the number of records in IP filter criteria, IP address range, IP subnet tables at instance level considering adverse performance on the instance if there are more number of records. But this can be increased by updating the corresponding system property as follows: Table name System property Default size sys_ip_filter_criteria glide.ip.criteria.filters.max_record_allowed_in_db 900 sys_ip_address_range glide.ip.address.max_record_allowed_in_db 30,000 sys_ip_address_subnet glide.ip.subnet.filters.max_record_allowed_in_db 1200 ReleaseUpdated for Xanadu release