Troubleshooting: Web Service Realm Fails or Times Out When Retrieving a User's Profile

Version Affected: All — a hotfix for Identity Platform 9.3.0–21.04 changes the default timeout value discussed in Cause 1 below
 
 

Overview

When a realm is configured to use a Web Service data store, end users may fail to authenticate, see an invalid-user error, or see "Error Retrieving Contact Information." In the Debug Log, this shows up as WebServiceProfileProvider.GetPropertyValuesBase failing to retrieve the user's profile from the Web Service endpoint (for example, https://<host>/<realm>/webservice/profilews.svc). There are two independent causes for this, covered separately below.

 

In this article

• Cause 1: The Web Service request times out (default 5 seconds)
• Cause 2: The response exceeds the maximum message size quota (262144 bytes)

Cause 1: The Web Service request times out (default 5 seconds)

The Debug Log shows a System.TimeoutException similar to:

WebServiceProfileProvider.GetPropertyValuesBase: finding user 'testuser1' got exception: System.TimeoutException:
The request channel timed out while waiting for a reply after 00:00:05. Increase the timeout value passed to
the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may
have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to
'https://localhost/secureauth5/webservice/profilews.svc' has exceeded the allotted timeout of 00:00:05.

Starting with a v9.3 hotfix, Identity Platform lowered the Web Service request timeout from 10 seconds to 5 seconds, to optimize lookup performance — with longer timeouts and enough concurrent slow requests, the Application Pool and the underlying server could become bogged down. The versions that start using the 5-second timeout are:

• v9.3.0 — Hotfix 23
• v19.07.01 — Hotfix 32
• v20.06 — Hotfix 9
• v21.04 — Hotfix 2

Any version released after these has the 5-second timeout included in the base code.

To resolve this, increase the timeout values in the web.config of the realm using Web Service:

1. If running a version between 9.3.0 and 21.04, apply the hotfix listed above for that version first.
2. Decrypt the web.config for the realm using Web Service. Do this on both the Web Service client realm (for example, the DMZ-facing realm) and the Web Service server realm (for example, the internal realm), since either side timing out can cause the same failure.
3. In the <appSettings> section, add or increase the following four keys (the value is in seconds — the example below sets them to 10):

<add key="WCFBindingSendTimeout" value="10" />
<add key="WCFBindingReceiveTimeout" value="10" />
<add key="WCFBindingOpenTimeout" value="10" />
<add key="WCFBindingCloseTimeout" value="10" />

4. Check whether these keys are already defined elsewhere in the web.config before adding them, to avoid a duplicate-key conflict. The value can be set to any duration appropriate for the environment — 10 seconds above is only an example.
5. Re-encrypt the web.config and test.

If overall slowness from Web Service timeouts is affecting active sessions, recycling the Application Pool clears any in-progress logins — users mid-login are refreshed and have to start again. This is only temporary relief, not a fix: the underlying cause is still the time it takes the realms to communicate with each other and with the data store.

Cause 2: The response exceeds the maximum message size quota (262144 bytes)

The Debug Log shows a System.ServiceModel.QuotaExceededException similar to:

WebServiceProfileProvider.GetPropertyValuesBase: finding user 'bob' profile got exception:
System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (262144)
has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding
element. ---> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming
messages (262144) has been exceeded.

This can result in missing attributes in SAML assertions issued by the realm, along with any other action that relies on the user's profile.

This happens when a property being returned to the Web Service realm is large enough that the response exceeds IIS's default message size limit of 262144 bytes (256 KB). This is typically the Fingerprints or Push Notification Tokens property, since the maximum count for each of these can be set to unlimited and tends to grow over time as a user enrolls more devices or logs in from more machines and browsers — but any property can grow large enough to trigger this.

To resolve this:

1. Review the size of the property being returned to the Web Service realm. For Fingerprints, this is usually the audio attribute in an Active Directory data store; for Push Notification Tokens, it's usually the jpegPhoto attribute. Check other properties too, not just these two.
2. Check the property directly on the data store, or use a Helpdesk realm to review the number of Fingerprints or Devices associated with the user.
3. Delete old or unnecessary Fingerprints or Devices as needed, or clear the whole attribute directly on the data store if required. Clearing the Push Notification Token means the user has to re-enroll their device to regain Push to Accept functionality.
4. To prevent this from recurring, configure a limit on the enrollment realm: the Total FP Max Count setting for Fingerprints, or the Max Device Count setting for Device Push Notification Tokens, both on the Multi-Factor Methods tab.

If the property's size can't be reduced, or needs to remain large, the message size limit itself can be increased instead:

1. Back up the web.config of the affected realm before making any change.
2. Open the System Info tab, scroll to the bottom, and click Click to edit Web Config.
3. Search for the WCFBindingMaxReceivedMessageSize and WCFBindingMaxBufferSize keys.
4. Increase both values — for example, double them. Both values should match each other. The default is 262144 bytes (256 KB); the maximum allowed is 2,147,483,647 bytes (2 GB).
5. Save and test.

Increasing this limit should be given careful consideration, since other limits elsewhere — such as maximum attribute sizes in Active Directory — can become the next restriction instead.

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.