How is TST suppose to work, keep getting db errors

[Pablo Vidaurri]

CAS 6.6.8

I'm using delegated auth to Azure AD using OIDC. Things seem to be mostly working but I noticed a couple of different db errors:

1. Delegated client identifier cannot be located in the authentication request ....
2. org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "postgres_jpa_ticket_entity_pkey"  Detail: Key (id)=(TST-6f93a6cc-3732-4dbb-9361-706f92a54787) already exists.

Issue #1, gives a false message as the error is actually thrown from DefaultDelegatedClientAuthenticationWebflowManager as a result of not finding the ticket in the ticket registry.  I think ticket is not found due to a couple of things:

1. Once user is redirected to Azure AD, I see TST ticket created in the registry. But the user is taking too long to enter credentials. By the time they are redirected back to CAS the TST has already expired and purged from ticket registry.
2. An issue with default cas.ticket.tst.time-to-kill-in-seconds=5 being too short. I have increased this to 120sec hoping that is enough time to provide credentials on Azure AD side. Along with this, I also have my registry cleaner set to every 60 seconds. It seems to be helping but still getting this error occasionally.

Issue #2, I'm not sure what is causing this one. Logging in and out, and logging in again somehow the same TST gets generated for the user and he TST from first login is still in the db. Perhaps the 120sec time to kill is too long but then I'm back at issue #1. I would think a new TST would be created at this point.

What is the logic of TST? I think this would be solved if TST creation is more unique with perhaps including timestamp.

Any suggestions?

-psv

[Pablo Vidaurri]

I'm still dealing with upset users over this issue ... any input on fine tuning time to kill or reg cleaner?