This could be sidestepped by having a rest endpoint to ask whether role R has access to resource X.
In fact, it looks like if you give the proxy access to ZK, then ZK can be dos'd via the proxy. -Ivan On Wed, Jan 9, 2019 at 4:32 PM Jai Asher <jai.ashe...@gmail.com> wrote: > > Ideally, it's better if we can authorize at proxy level and reject all > unauthorized connections before connecting to the broker - lesser chances > of broker being Dos’d. However in order to authorize a role, we needed > access to zookeeper, connection to zookeeper was something we wanted to > avoid for proxy since it is on a public IP - hence we authenticate at proxy > level and authorize at the broker, but that’s not the ideal configuration. > > On Wed, Jan 9, 2019 at 3:10 AM Ivan Kelly <iv...@apache.org> wrote: > > > > Assume a role/principal R has permissions to produce on a namespace. > > If > > > we don't authenticate at the proxy then anyone (attacker) can say that > > they > > > belong to role R and connect to the proxy, the proxy will forward the > > role > > > name to the broker which will authorize it and allow access. Instead, we > > > need to *authenticate* at the proxy and reject all connections which are > > > trying to falsify their credentials and then the broker will reject all > > > roles/principal which are not *authorized* to access the namespace. > > > > Well, yes, that's what I would expect to happen. So what is the point > > of have auth*ORIZATION* in the proxy? If the broker is going to apply > > the authorization anyhow, shouldn't we do authentication at the proxy > > level? > > > > -Ivan > >
