vouch-proxy
vouch-proxy copied to clipboard
vouch
allow user by subdomain
Hello, Is it possible to define user whitelist by subdomain ? or do i need to do a docker instance ( and a config by subdomain ?
if i set domain to example.com. I would be great to define a spécific whitelist for app1.example.com and another one for app2.example.com
maybe something like that (but better ;-) )
domains:
- example.com
# set allowAllUsers: true to use Vouch Proxy to just accept anyone who can authenticate at the configured provider
# allowAllUsers: false
# Setting publicAccess: true will accept all requests, even without a cookie.
# If the user is logged in, the cookie will be validated and the user header will be set.
# You will need to direct people to the Vouch Proxy login page from your application.
# publicAccess: false
# whiteList
whiteList:
- BySubdomain:
name: app1
users:
- [email protected]
- [email protected]
- BySubdomain:
name: app2
users:
- [email protected]
- [email protected]
What could be great, is to define whitelist in a separate file whitelist.lst by example and be able to have filename like whitelist.{subdomain}.lst
@artagel has documented how to accomplish this using OpenResty... https://github.com/vouch/vouch-proxy#advanced-authorization-using-openresty
It's not quite as simple as a whitelist per domain but it can be done.
As a work around, i'm running 2 vouch servers on one instance but using different ports. So 9090 will map to x.domain.com and a config with its own whitelist while 9091 will be for y.domain.com but the config has a different white list.
I found this pretty easy to set up. the only other thing i had to do was tell nginx which subdomains should use which ports
@bnfinet Are you interested in a PR adding this functionality? I personally need this feature and don't want to switch my whole stack from Nginx to OpenResty because of it.
The 'vouch.domains' option is a whitelist provided the configured idp returns an email address. The email is checked to be within a domain.
The original use case was/is that anyone who can authenticate to a Google Apps for business group (configured by domain) is authorized.
Are you proposing something different than this?
On Mon, Mar 23, 2020, 12:02 PM Mahdi Mohaveri [email protected] wrote:
@bnfinet https://github.com/bnfinet Are you interested in a PR adding this functionality? I personally need this feature and don't want to switch my whole stack from Nginx to OpenResty because of it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vouch/vouch-proxy/issues/114#issuecomment-602795829, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJUV2ZXCAJUJTMO5LL3MIDRI6W45ANCNFSM4HJKFMMA .
sorry @mmohaveri I was replying via email and didn't realize you were responding into an old thread.
Are you saying you need the subdomain functionality? Each user would be associated with a specific subdomain (or host)?
Yes, I would prefer to have the option to whitelist specific users for specific domains while using Nginx.
What IdP are you using?
You could use multiple VP instances side by side, using one whitelist per
instance, pointing each nginx server{} stanza at the appropriate instance.
On Tue, Mar 24, 2020 at 2:41 AM Mahdi Mohaveri [email protected] wrote:
Yes, I would prefer to have the option to whitelist specific users for specific domains while using Nginx.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vouch/vouch-proxy/issues/114#issuecomment-603134150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJUV2YPXPPPAZ2Y42ZFLDLRJB56LANCNFSM4HJKFMMA .
Currently I'm using Gitea
Yeah, that's definitely possible, but a little too much for a simple whitelisting.
If client_id/client_secret would be configurable per (sub)domain, different clients for each site can be configured at the IdP. Perhaps with the help of the map proposed in #302.
Another option would be to make the auth provider configurable per subdomain and allow multiple entries in oauth. This would be a clean solution regarding #302.
