caddy-security
caddy-security copied to clipboard
greenpau
feature: ability to share auth data between caddy instances (high availability)
A clear and concise description of what you want the system to do.
There was a PR in caddy-auth-portal implementing this (branch implement-oauth-for-ha-systems. Would be nice to implement that: https://github.com/greenpau/caddy-auth-portal/pull/174
@greenpau i'm thinking about developing this feature since i really need this feature, i need to support redis as a cache implementation to oauth, but i would like to know from you what i need to implement to make this a valuable feature for this plugin :)
@greenpau why did you closed this one? I just started working at this...
why did you closed this one? I just started working at this...
@hurrycaner , once you have your proposal ready (prior to coding), please post it here and I will reopen. There are changes happening right now related to backends: https://twitter.com/GreenbergTech/status/1507346211359100929
Hey @greenpau, the idea is to bring the PR https://github.com/greenpau/caddy-auth-portal/pull/174 to go-authcrunch repository, considering your comments here. Is there anything else i should consider?
@hurrycaner , I am interested to see how your are planning to integrate that code in go-authcrunch. For example, I don’t want to create dependencies to external libraries (i.e. want to keep things pure), unless absolutely necessary.
-
What would Caddyfile look like?
-
What would it “attach” to, etc.
@greenpau thank you for your quick responses :)
{
security {
cache <type> {
<configurations>
...
}
}
}
- Well, each cache implementation would depend on some library, in the PR mentioned before, gomemcache was used, i was thinking about using https://github.com/eko/gocache, so the responsibility of handling cache won't be another thing to handle and maintain and will minimize dependencies, because it will interface cache handling, including for in-memory.
@hurrycaner , here is the change separating backends into identity stores and providers: https://github.com/greenpau/go-authcrunch/commit/dc55c406743e49b8905c6ec6a94e7500b380f505
I still need to implement Caddy side of all of it ...
Well, each cache implementation would depend on some library, in the PR mentioned before, gomemcache was used, i was thinking about using https://github.com/eko/gocache, so the responsibility of handling cache won't be another thing to handle and maintain and will minimize dependencies, because it will interface cache handling, including for in-memory.
Understood. Will think about it ... what exactly are you planning to cache, e.g. identity provider of type OAuth - storing state?
@greenpau I plan to store state, so i can use multiple instances of caddy with auth portal.
@hurrycaner , I am switching to “interface-driven” development here. This means that “go-authcrunch” repo would accept the registration of interfaces and the processing logic will happen in the implementation of the interface.
You will implement the interface in “hurrycaner/mycaching”solution. The “caddy-security” will have a parser that will import the “ hurrycaner/mycaching” and would register it as an interface in “go-authcrunch”.
This way, you are in control of the caching. The “ hurrycaner/mycaching” becomes a “plugin” of “caddy-security,” which is a plugin of caddy.
With the last few releases I introduced more interfaces in “go-authcrunch” and believe the above system would work well. Just need to develop the necessary plumbing.
Did I understand correctly that if I have more than one caddy replica, then this plugin will not work?
Can you store data in s3?
Did I understand correctly that if I have more than one caddy replica, then this plugin will not work?
@fannyfan414 , yes, unless you make traffic from a particular source stick to the same replica/instance, i.e. sticky session cookie.
@greenpau Any news/updates for high availability? Maybe here can be the same logic as caddy store tls certificates at s3?