Issue
Chef Automate users report being logged out of the browser UI without warning and frequently need to re-authenticate through the login portal. Chef Automate looks healthy from a system perspective and neither the automate-ui nor the dex services show any signs of issue.
Environment
All versions of Chef Automate and Chef Infra Server (this has general application across any system/environment which uses an external auth system)
Resolution
There are a few options to consider depending on your topology:
- This only applies to SSO/SAML/AD via SAML based systems. If your authentication choice is capable of extending token lifetimes, set this to something you are comfortable with, for example 12 hours. This would mean only authenticating once per working day would be necessary.
- Point Chef Automate at a specific node within your authentication cluster to ensure that it always re-queries the same node regarding token expirations
- Place a load balancer in between the Chef Automate instance and the authentication cluster to allow sticky sessions. The client could then remain stuck to the correct domain controller until either the client or server dies.
Cause
When Chef Automate is configured to talk to an external authentication system, it will likely require that any downstream infrastructure is capable of handling session re-authentication and that either the authentication backend is a cluster-aware system capable of replication of requests across all nodes, or that the origin from which the authentication approval came from is the same node that is referred to for the duration of the user session.
In the context of LDAP for example, if a user's session is pointed at an FQDN resolving to a cluster of domain controllers which receive requests on a round-robin basis, then it is unlikely that the same session will reach the same domain controller.
It may be possible to use a replication store across domain controller clusters, but this remains untested and unverified internally at Chef.