Question: HA and user sync on SAML
mvn-bachhuynh-dn opened this issue · comments
Hi there,
I have 2 questions:
Is there any way to High Availability Subspace server? Or we just sync-up the data folder.
I used JumpCloud as IDP for SSO. It works perfectly, but when I deleted/disabled/suspended a user on JumpCloud, the user's profile still available on Subspace, the device's installed of the user still connect VPN server. How could we fix this stub?
Thank you so much!
Hey there!
With 99% certainty there is no internal sync method for HA. What I came up with when implementing where I work is a main node, that would serve the web page and be responsible to update and upload the config file to a centralised storage, and worker nodes that periodically downloads and updates the wireguard config. You have to load-balance with a network load balance.
As I use AWS, I use elastic IP properties to define which is the main and worker nodes. The first node that successfully allocates the IP to itself becomes the main node and configures a cronjob to upload the config file. All other nodes will fail when trying to allocate the IP and will configure a cronjob to pull the config file.
This is all in theory, because I didn't have to actually implement the HA (a t3a.micro instance is more than capable of handling the amount of users we have).
Regarding deleting users automatically, it is tracked in issue #98 . Back then I volunteered to investigate, but couldn't find a way to natively sync with the IdP. It seems we need vendor specific routines that will use specific credentials (like service accounts) with permissions to read users attached to the Subspace SSO application in the IDP and deprovision/create users accordingly.
I wanted to do something different. My idea was to implement a userspace client application for subspace. This way we could for instance use the tunnel to communicate with the server, but only allow traffic after the user authenticates a second time with the IDP (with a refresh token or whatever). This has the upside to open ways to rotate keys, push server-side configs (for instance to propagate any server changes to DNS, split tunnel etc...) and provide a second authentication factor with the IDP. Downside is that maintaining userland apps is hard when it comes to cross platform implementation, security and updates.
Anyway, this is all nice and interesting, but I can't even begin exploring these ideas because the rest of the team has been silent for a while and I can't unilaterally approve features. We need a couple of extra pair of hands.
Kind Regards!
Hi @gchamon Thank you so much for your response!
Hope the team could improve the SSO process soon ❤️