Userapplication Timeout issue

ChrisKnudsen 1 month ago

Hi,

We run userapplication 3.8.7 at a client in a docker cluster enviroment and we are having some issues with sessions beeing broken - forcing the user to login several times in a short period.

We see this in catalina.out :

09:37:59.247 [https-jsse-nio-18543-exec-40] DEBUG com.netiq.idmdash.context.RefreshTokenServlet - [IDMDASH] OSP exception: access_denied:revtoken:Refresh token has been revoked.
09:37:59.247 [https-jsse-nio-18543-exec-40] DEBUG com.netiq.idmdash.context.RefreshTokenServlet - [IDMDASH] Refresh token has been revoked.
com.netiq.idmdash.oauth.exception.InvalidCredentialsException: Refresh token has been revoked.
        at com.netiq.idmdash.context.RefreshTokenServlet.handleRequestError(RefreshTokenServlet.java:417) ~[classes/:?]
        at com.netiq.idmdash.context.RefreshTokenServlet.getAccessTokenInfo(RefreshTokenServlet.java:381) ~[classes/:?]
        at com.netiq.idmdash.context.RefreshTokenServlet.doGet(RefreshTokenServlet.java:191) ~[classes/:?]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:529) ~[servlet-api.jar:4.0.FR]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:623) ~[servlet-api.jar:4.0.FR]
etc..

Does anyone have any ideas on what we can try?

The issue seems to be isolated to one of the servers (the error shown above is only seen in catalina.out on one of the servers)

(ism-configuration.propperties is equal on both servers)

Top Replies

Verified Answer

+1 Geoffrey Carman 1 month ago

Never seen a refresh token revoked.

One thing t do is clear the oidpInstances (or is it oidpInstanceData) attribute on the users.

Did you change the Refresh token lifespant/TTL in the ism-configuration.propeties? WHere pehaps you made the refresh and Access token windows overlap backwards? Access should be short and refresh should be long. Maybe you reversed that? (Does not explain why one node and not the other).
Cancel
Vote Up +2 Vote Down

Sign in to reply

Reject Answer

Cancel
Verified Answer

+1 Norbert Klasen 1 month ago

Do you run OSP alongside IdentityApps on your cluster hosts? Do you have the same OSP keystore everywhere?

Are all your hosts using the same eDirectory without a loadbalancer in front? Refresh tokens are stored in the users' oidpInstanceData attribute. Therefore replication delays can cause these issues if you're using different eDirectory instances.

Clearing oidpInstanceData (e.g. because it grew to large) will also revoke all refresh tokens.
Cancel
Vote Up +2 Vote Down

Sign in to reply

Reject Answer

Cancel
0 Geoffrey Carman 1 month ago in reply to Norbert Klasen

To clarify Norbert's excellent point...

If you have two OSP instances (One per cluster node) then each will write to eDir when you use that cluster node. So you might have a refresh token from Node A, that is not working on Node B. Or something like that.
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ChrisKnudsen 1 month ago in reply to Geoffrey Carman

Hi, we have the following settings for TTL in the userapp ism:

com.netiq.idm.osp.oauth.accessTokenTTL = 60
com.netiq.idm.osp.oauth.refreshTokenTTL = 2592000

com.netiq.idm.osp.oauth.public.refreshTokenTTL = 2700

Are there any other lines that could cause the problem?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ChrisKnudsen 1 month ago in reply to Norbert Klasen

I will check the individual OSP ism files to see wich "DirectoryService/realms/jndi/params/AUTHORITY" they point to - and report back.

As i understand your reply - they should point to the same server - right?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Norbert Klasen 1 month ago in reply to ChrisKnudsen

Yes, all should be pointing to the IDV engine that is running RRSD and UAD.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ChrisKnudsen 1 month ago in reply to Norbert Klasen

They both point to the same idv - wich is also runs the idv, rrs and ua.

We are going to try to up the TTL (com.netiq.idm.osp.oauth.accessTokenTTL) from 60 secs to 5 mins and see if its get more bearable :)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Geoffrey Carman 1 month ago in reply to ChrisKnudsen

Norberts other important point you did not answer is whether they share the same OSP Private key? I.e. The encryption key for oidpInstances, is it shared or two different keys?
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ChrisKnudsen 1 month ago in reply to Geoffrey Carman

Thank you for noticing, we will look into that
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ChrisKnudsen 1 month ago in reply to Geoffrey Carman

The keystores are identical, so the private key should be the same...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Menu

Identity Manager User Discussions

Userapplication Timeout issue

Top Replies

Verified Answer

Verified Answer

Resources