Troubleshooting: API Returns "Could Not Resolve Fingerprint With ID"

Version Affected: IdP 8.2 and later
 
 

Overview

Sending a fingerprint_id to the Device Fingerprinting (DFP) confirmation endpoint (POST /api/v1/dfp/confirm) returns:

ApiResponseHTTPStatusCode="OK" ApiResponseStatus="not_found" ApiResponseMessage="Could not resolve fingerprint with ID <id>"

Cause

When the DFP validation endpoint (POST /api/v1/dfp/validate) doesn't find the fingerprint in the datastore, or finds it as found_for_update, the API returns a fingerprint_id and caches it in memory for a short time -- by default, 2 minutes, set by the web.config app setting key Api.HttpRequestValidityPeriodInMinutes. When that fingerprint_id is then sent to the confirmation endpoint, the API follows this logic:

if fingerprint_id is found in the cache AND the datastore:
    update the existing fingerprint in the datastore
    return "verified", "Fingerprint has been confirmed."

else if fingerprint_id is found ONLY in the cache:
    add a new fingerprint to the datastore
    return "verified", "Fingerprint has been confirmed."

else if fingerprint_id is found ONLY in the datastore:
    return "found", "Fingerprint exists."

else (found in neither):
    return "not_found", "Could not resolve fingerprint with ID <id>"

So the error means the fingerprint doesn't exist in the datastore, and the cache no longer has it either -- either because the cache entry expired, or because a load-balanced request reached a different IdP node than the one that originally cached it.

Resolution:

Review the logs to confirm the time between fingerprint validation and confirmation stays within Api.HttpRequestValidityPeriodInMinutes. Adjust the API client's timing, or increase Api.HttpRequestValidityPeriodInMinutes, as needed.

If the IdP is in a load-balanced pool, make sure session affinity/persistence is maintained so API requests don't bounce between different nodes.


 

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.