You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If running multiple instances of the proxy it'd be useful to be able to connect an external store (e.g. redis) for request IDs. Currently request IDs are stored in memory (in a dictionary) which means if you're running 2 instances of the proxy, the same instance must receive the SAML response from the IDP.
Doing this should allow:
multiple instances of the SAML proxy to be run - allowing for easier horizontal scaling
prevents outstanding auth Journey's being broken if an instance needed to be restarted
Possible Solution
Allow redis (or other) store to configured and used in SAML2 proxy backend
use redis for oustanding_queries with an in memory fallback (if not configured)
The text was updated successfully, but these errors were encountered:
a possible easy workaround is to configure sticky sessions/cookies on your load balancer, so that requests end up on the same instance of the proxy. There are real deployments that work this way atm.
Having said that, we have been trying to avoid storing state on the server-side. This doesn't seem to be feasible anymore. I am looking towards introducing a storage backend to store session information and allowing plugins access to it; so, not just for request IDs.
In particular Redis is a good choice because it allows us to set a TTL to records.
I will come back to this with more info, but this is timely as support for logout (#431 and #444) would also require to keep some state on the proxy side.
Code Version
8.2.0
Use case
If running multiple instances of the proxy it'd be useful to be able to connect an external store (e.g. redis) for request IDs. Currently request IDs are stored in memory (in a dictionary) which means if you're running 2 instances of the proxy, the same instance must receive the SAML response from the IDP.
Doing this should allow:
Possible Solution
The text was updated successfully, but these errors were encountered: