feature: ability to share auth data between caddy instances (high availability)

[hurrycaner]

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]

@hurrycaner , thank you for the issue! 👍

[hurrycaner]

@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]

Closing and moving to backlog for now.

[hurrycaner]

@greenpau why did you closed this one? I just started working at this...

[greenpau]

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

[hurrycaner]

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?

[greenpau]

@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.

1. What would Caddyfile look like?

2. What would it “attach” to, etc.

[hurrycaner]

@greenpau thank you for your quick responses :)

1. {
   security {
   cache <type> {
     <configurations>
     ...
   }
   }
   }

2. 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.

[greenpau]

@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?

[hurrycaner]

@greenpau I plan to store state, so i can use multiple instances of caddy with auth portal.

[greenpau]

@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.

[fannyfan414]

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?

[greenpau]

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.

[fannyfan414]

@greenpau Any news/updates for high availability? Maybe here can be the same logic as caddy store tls certificates at s3?

[christoph-kluge]

@greenpau just stumbled upon the same issue after testing caddy in a HA deployment.

caddy@v2.8.4 caddy-security@v1.1.29

Any plans to support caddy's native configuration store for this in the next upcoming releases?

[greenpau]

Any plans to support caddy's native configuration store for this in the next upcoming releases?

@christoph-kluge , not in the immediate future. This one is on backlog. I might need this feature in Q3 2024.