By: Lukasz Golinski named 31 May 2022 at 6:40 a.m. CDT

6 Responses
Lukasz Golinski gravatar
## Expected behavior Scaling oxauth to multiple pods should not cause additional rest requests to be performed from within authentication scripts. ## Actual behavior In our acr scripts we perform some rest calls. Here is the pattern that we use to perform such requests: ``` http_service = CdiUtil.bean(HttpService) http_client = http_service.getHttpsClient() http_service_response = http_service.executePost(http_client, uri, auth_data, headers, body) ``` In case oxauth is scaled to 1 replica everything works fine. We observe that scaling oxauth to more than 1 replica cause that approximately one out of 10 authentication process fail due to the fact that some rest calls are performed twice. Do you perhaps know what could be the cause of such behavior?

By Mohammad Abudayyeh staff 01 Jun 2022 at 3:12 a.m. CDT

Mohammad Abudayyeh gravatar
Hey, No thats the first we have heard of. Can you try to preserve the client session to the pod. You can do that by adding the following to the oxauth service section: set `service.spec.sessionAffinity` to `ClientIP`. By default the session held by the service is 3 hours and can be modified by setting `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`. This will force each client to stay connected to the oxAuth it connected to. If its the other way around meaning oxAuth is the one executing multiple requests than we need to dig deeper.

By Mohammad Abudayyeh staff 02 Jun 2022 at 3:37 a.m. CDT

Mohammad Abudayyeh gravatar
Any news ?

By Lukasz Golinski named 02 Jun 2022 at 6:06 a.m. CDT

Lukasz Golinski gravatar
Hi Mohammad. I checked the session affinity option. However it didn't work. I also performed some further tests and i have an assumption what could be the cause of performing additional requests. It seems that in some cases step counter fail to be updated or we try to read it from the cache before the update occurs. I attach two log files. ha-success.txt - shows the positive scenario (when everything works as expected) ha-claims-error.txt - shows the logs when prepareforstep 1 is being perfomed twice - therefore two rest calls occur. 1. line 6... prepareForStep 1 2. line 20... getPageForStep 2 3. line 22... prepareForStep 1 again... Since oxAuth is scaled to 3 instances I added an integer after the timestamp of each log line to show in which instance the above method execution took place.

By Michael Schwartz Account Admin 03 Jun 2022 at 10:56 a.m. CDT

Michael Schwartz gravatar
@Thomas Gasmyr.Mougang can suggest some logging Idemia can add into their script to help give us more data?

By Thomas Gasmyr Mougang staff 06 Jun 2022 at 5:42 a.m. CDT

Thomas Gasmyr Mougang gravatar
Hi Lukasz, > Since oxAuth is scaled to 3 instances I added an integer after the timestamp of each log line to show in which instance the above method execution took place. From the first log(ha-success.txt) i can see two integers used after the timestamp(1 and 2) which meam that you have two oxauth instances, but you are claiming that it works only when you have one instance of oxauth. From the second log file(ha-error.txt), i can see see htree intergers meaning three instances, in this case we need a way to know which instance is handling the request. Normally only one instance should carryout the whole auth steps for a given client connexion, but the log is not clear about that.

By Lukasz Golinski named 20 Jun 2022 at 2:35 a.m. CDT

Lukasz Golinski gravatar
Hi, Doing additional tests it seems that the cause of such behavior is caused by steps synchronization. In our scenario we have 2 steps defined. Step 1. which points to /eid-login.xhtml Step 2. which points to custom /set-cookie.xthml page It seems that from time to time (when oxauth is scaled up) after the positive authentication process... when user is redirected to set-cookie page and performs prepareForStep method on the script side current step is not yet updated, therefore it causes invocation of prepareForStep method with step 1.