Synchronizing Tokens

When a user has authenticated successfully with a server, a token is issued that is passed back and forth in a cookie. These tokens may be long-lived with a default expiration time of seven days and normally automatically reissued. So, when the server is regularly used, the user will rarely need to log in again. Similarly, API tokens never expire.

Normally, a token issued by one server is only valid on that server. The server keeps track of issued tokens and validates each incoming token against its stored tokens. Furthermore, tokens are revoked when an administrator logs out a user, and the token
is removed from the server’s list.

If there are multiple servers that are being used as a cluster with a load balancer in front, they should be configured to have synchronized tokens. Even if the load balancer uses sticky sessions as it should, a token is typically valid for a longer time than a session lasts, and the user should not have to log in again just because a new session is directed to a different server than last time.

Token synchronization uses a different mechanism from repository synchronization. The repository stores content with its change history, and there are scenarios where the user may want to synchronize one and not the other. For example, there may be one QA server and one production server then use a common login.

Tokens are synchronized through the cluster shared store. By default, this is just a subdirectory <AppData>/shared/ which is not synchronized. The server also uses this store for other types of data that should be shared between servers but isn’t technically content (i.e., fonts that have been uploaded, scheduled tasks, users' most recently viewed workbooks, and other things).


To enable token synchronization:

  • Change the property cluster.store.type from its default DIRECTORY to some other supported type (see following section).
  • Configure the selected store type (again, see below).
  • Ensure all servers use the same cookie name in authentication.token.cookie, or a cookie issued by one server would not be visible to another.
  • Ensure all servers (i.e., validating server and the one that issued the token) have the same <AppData>/token_secret. This secret is used to sign and validate tokens.

 

Cluster Shared Store: ZooKeeper

You can use Apache ZooKeeper as the shared storage for a Panopticon server cluster. ZooKeeper is installed and run as a separate external server, and you instruct Panopticon how to connect to it. Simply put, ZooKeeper is a hierarchical key-value store. ZooKeeper can also run in replicated mode with failover if you want to ensure that the cluster shared store does not become a single point of failure.

To choose ZooKeeper as cluster store:

  1. Install ZooKeeper and ensure it is running when Panopticon starts.
  2. Change the cluster.store.type property from its default value DIRECTORY to ZOOKEEPER.
  3. Add the (required) property cluster.store.zookeeper.connect and set it to a standard ZooKeeper connect string. This is a comma-separated list of one or more ZooKeeper servers in <host>:<port>[/<chroot>] format.

    Example:

    cluster.store.type=ZOOKEEPER
    cluster.store.zookeeper.connect=zkhost1:2181/pano,zkhost2:2181/pano

 

 

(c) 2013-2024 Altair Engineering Inc. All Rights Reserved.

Intellectual Property Rights Notice | Technical Support