-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Several different JWT with one instance of Haproxy #34
Comments
I think I understand. You use your DEV load balancer as a fallback for your production traffic if the PROD load balancer fails. I would be concerned about mixing DEV and PROD. Wouldn't it make trying novel, whacky stuff in DEV risky, since PROD depends on DEV as a fallback? But my opinions aside, it should be possible to implement this. One complication could be loading the pub key file. HAProxy can't load files after startup. Possibly, we could paste the key contents into the haproxy.cfg file. |
I think support for multiple public keys would be useful to validate the signature of JWTs signed with different private keys depending on audience / services and to support graceful private key rotation without impacting user experience. |
Did you know that HAProxy now supports validating JWTs natively? Using that, you could choose a different public key depending on an ACL condition. You would adapt this line to load a different PEM file, based on a condition.
from the blog post, https://www.haproxy.com/blog/verify-oauth-jwt-tokens-with-haproxy. Should we archive this Lua project in favor of the native JWT verify feature? If so, feature requests could go to the core HAProxy team. |
Thanks! I just wanted to port the installation script to support alpine when I saw this. I will give the built-in verifier a go! |
Addressed this topic as part of #40 |
Since the public key of the token is assigned in the 'global' section, using multiple different tokens (from different authentication servers) seems impossible. However, it may be necessary.
For example, we have a cluster of three Haproxy+Keepalived load balancers. When everything is ok each load balancer serves as an API gateway for one environment - dev, test, or production. But if one of the load balancers fails, its virtual IP address switches to the next one, and - since it has the same configuration as the failed one - it starts serving two environments instead of one.
However, the REST API of each environment is protected by its own token, meaning the public key in OAUTH_PUBKEY_PATH is different for each environment. And this variable is specified in the 'global' section, so there cannot be multiple of them. Hence, our cluster scheme with JWT is not applicable. Can't we embed these parameters in the 'frontend' section instead?
The text was updated successfully, but these errors were encountered: