<div dir="ltr">I can't speak to the official recommended way to do this, but I am running a local instance of MariaDB with Galera on each node as my StorageService. Galera syncs the tables across all of the nodes so they all have the session information regardless of which node in the cluster is hit by the request. This doesn't help if a node fails during authentication (i.e. between the password and MFA steps), but once the session is established the user (or the RP) can hit any node in the cluster and that node can validate the token / cookie / etc. <div><br></div><div>You could also point all your nodes to a single data source, but then you'd have a single point of failure. </div><div><br></div><div>-Matt</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 20 Jul 2026 at 12:01, B via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Saturday, July 18th, 2026 at 10:28 AM, Scott Cantor via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br>
<br>
> <br>
> > But that doesn't apply to attributes for claims, where the data stays on the node, correct?<br>
> <br>
> Attributes generally come from elsewhere, and get resolved at a lot of different points in different requests. In the rare cases that the data only exists during a authorization reques, it can be encoded into the tokens issued for recovery later, so it's trivial (size aside) to resolve data on one server and reissue it from the UserInfo endpoint on another by pulling it from the access token.<br>
> <br>
<br>
So going back to your first reply, and keeping in mind the testing problem, by default does the code returned to the browser by /idp/profile/oidc/authorize on node A contain enough information for node B to run the resolver, so it can respond to a token or userinfo request?<br>
<br>
Thanks<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>