Our team is seeing timeouts when calling listUsers with default parameters with the Okta Java SDK Client.
We have seen that there is a known limitation for certain types of admins when calling listUsers, and we believe this is the case for what we are seeing: Read Only Admins can make the call fine, but a Custom Admin with permissions for reading Users and Groups times out.
However, when making this same call via powershell, there is no timeout.
Is there a way to avoid timeouts while still using a Custom Admin with the correct Read permissions? Would using pagination params help? We want to avoid retries as each of these could time out and we are wary of rate limits.
If there was a permission issue an immediate error would be returned.
Okta doesn’t give any sort of priority on an API call based off of role. There is an ability to specify specific rate limits for API Tokens if being used, but if a rate limit is hit for a token an immediate 429 should be returned.
It would be helpful if you could provide your Org details and the exact date/time of one one of these incidents. Support can check if the call is reaching use and what is returned.
Might also check what your client retry settings are,
I don’t think this is exactly a “permission issue”. I linked the known limitation in the Okta docs that we seem to be encountering: Users | Okta Developer . Timeouts for listing users/groups for Custom Admins scoped to only view their users.
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
at com.okta.commons.http.httpclient.HttpClientRequestExecutor.executeRequest(HttpClientRequestExecutor.java:180)
... 39 common frames omitted
Wrapped by: com.okta.commons.http.HttpException: Unable to execute HTTP request - retryable exception: Read timed out
at com.okta.commons.http.httpclient.HttpClientRequestExecutor.executeRequest(HttpClientRequestExecutor.java:183)
at com.okta.commons.http.RetryRequestExecutor.doExecuteRequest(RetryRequestExecutor.java:147)
at com.okta.commons.http.RetryRequestExecutor.executeRequest(RetryRequestExecutor.java:120)
at com.okta.sdk.impl.ds.DefaultDataStore.execute(DefaultDataStore.java:470)
at com.okta.sdk.impl.ds.DefaultDataStore.lambda$getResourceData$2(DefaultDataStore.java:213)
at com.okta.sdk.impl.ds.DefaultFilterChain.filter(DefaultFilterChain.java:47)
at com.okta.sdk.impl.ds.cache.WriteCacheFilter.filter(WriteCacheFilter.java:34)
at com.okta.sdk.impl.ds.DefaultFilterChain.filter(DefaultFilterChain.java:52)
at com.okta.sdk.impl.ds.cache.ReadCacheFilter.filter(ReadCacheFilter.java:42)
at com.okta.sdk.impl.ds.DefaultFilterChain.filter(DefaultFilterChain.java:52)
at com.okta.sdk.impl.ds.DefaultDataStore.getResourceData(DefaultDataStore.java:225)
at com.okta.sdk.impl.ds.DefaultDataStore.getResource(DefaultDataStore.java:181)
at com.okta.sdk.impl.resource.group.DefaultGroup.listUsers(DefaultGroup.java:229)
...
We are seeing this for customers using our application, and so do not have access to their organization details, except what is provided to us.