Anders,
The LTPA token does contain an expiry, however it is written as the number of seconds since epoch - which means it is timezone agnostic (epoch time is in UTC). So, Jon is correct and the different timezones should not impact the expiry time of the LTPA token.
The timeout of the token itself is calculated as either twice the configured lifetime of a session, or twice the configured ltpa-cache-entry-lifetime value.
Have you checked to ensure that the clocks are synchronised between the two containers? Even though they might be configured in different timezones the clocks should still be synchronized (i.e. represent the same absolute time). I would suggest that you try increasing ltpa-cache-entry-lifetime to some hideously long value to see if the issue is actually due to the LTPA token expiry, and is not due to something else.
I hope that this helps,
Scott.
------------------------------
Scott Exton
IBM
Gold Coast
------------------------------
Original Message:
Sent: Thu September 10, 2020 10:28 AM
From: Anders Domeij
Subject: timezone when deploying Helm charts
Short version...
Our suspicion is based on:
In the test Web reverse proxy : Docker compose -- the time in the container matches that of the Host.
From test web reverse proxy: ltpa-login to backend (also local time) works. :-)
Note: ISAM v 9.0.7
In the ISVA reverse proxy: Kubernetes -- the time in the pod (-2h) <> Host time
From ISVA reverse proxy: ltpa-login to backend (same as above) error seen in log "Invalid Security token" :-(
Note: ISVA 10.0.0.0
Sorry for the short version (out of time for now)
Rgds
------------------------------
Anders Domeij
CGI Sweden AB
Original Message:
Sent: Thu September 10, 2020 08:08 AM
From: Jon Harry
Subject: timezone when deploying Helm charts
Hi Anders,
The timezone setting should not impact the times associated with cookies or tokens created by Verify Access. These should all be set based on UTC regardless of the timezone.
If you find that things are going wrong, and you suspect time differences are the issue, it's more likely that the source and destination systems have different
absolute times set. Make sure that the time is correct for the timezone that is set. Using network time to keep all times correct is recommended.
If you have logs for a specific failure then please share something.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Thu September 10, 2020 07:20 AM
From: Anders Domeij
Subject: timezone when deploying Helm charts
>Looking at the internals of the Verify Access charts, it doesn't look like this is being set and so some default will be used (I hope that's UTC).
Actually I think it will be the timezone of the Kubernets Cluster that is used if no overide is done in the pod deployment.
Again unfortunately (for us), the documentation for setting up Kubernetes clusters doesn't emphasize the need to consider s not very clear so pods deployed to our cluster are running UTC.
The remedy to that problem would be to scrap the cluster restart it with our local timezone and redeploy all charts (from scratch).
Not an exciting venue.
Rgds
------------------------------
Anders Domeij
CGI Sweden AB
Original Message:
Sent: Thu September 10, 2020 06:28 AM
From: Jon Harry
Subject: timezone when deploying Helm charts
Hi Anders,
The timezone for a Verify Access container (used when writing time into logs etc.) is set based on environment variable CONTAINER_TIMEZONE.
Looking at the internals of the Verify Access charts, it doesn't look like this is being set and so some default will be used (I hope that's UTC). I think this is an oversight - the charts will have to be updated to have timezone as an optional input parameter to be passed into all deployment definitions. Something we can look at in the future.
Feel free to open an ISSUE on GitHub or happy to get a PULL request from you if you want to add it into the charts yourself :)
Is the a blocker for your deployment?
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Thu September 10, 2020 05:44 AM
From: Anders Domeij
Subject: timezone when deploying Helm charts
How do we set the correct ("Europe/Stockholm" in our case) timezone for "config/runtime/admin/reverse proxy" pods, when deploying from the IBM Chart github repo?
The Kubernetes cluster runs with timezone "UTC".
Rgds
------------------------------
Anders Domeij
CGI Sweden AB
------------------------------