> On Dec. 15, 2017, 9:41 p.m., Chug Rolke wrote: > > This seems like a decent approach for starters. > > > > It may have an issue when multiple vhosts come in to the router on the same > > port. All of the connections then are sent to the same authServicePlugin > > authService port for authentication and authz. In the current policy scheme > > the policy is decided later when the AMQP Open frame's hostname field is > > used as the name of the vhost policy. Then the user name is looked up in > > that vhost policy section. > > Gordon Sim wrote: > The vhost name can be sent in the sasl-init frame which allows the actual > auth service to determine which 'realm' to authenticate against. At present > in the plugin this is always taken from configuration, however it could be > taken from what the client sends. > > Chug Rolke wrote: > It could. Adding the sasl-init hostname sounds like a worthy addition > precisely for the realm spec and the authentication. > > Qpid and AMQP.Net Lite clients have gone through some effort to pass the > TLS Server Name Indication (SNI) through to the AMQP Open hostname. The > clients would need to add support to ensure that the SNI hostname makes it > into sasl-init properly. Having three sources of 'hostname' (external-ssl, > sasl-init, AMQP Open) is not ideal but is manageable.
At present proton doesn't actually read the hostname from sasl-init, so that needs to be exposed before we can pass it through (where a specific value is not set though config). - Gordon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/64645/#review193976 ----------------------------------------------------------- On Dec. 20, 2017, 5:40 p.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/64645/ > ----------------------------------------------------------- > > (Updated Dec. 20, 2017, 5:40 p.m.) > > > Review request for qpid, Chug Rolke, Ganesh Murthy, and Ted Ross. > > > Bugs: DISPATCH-901 > https://issues.apache.org/jira/browse/DISPATCH-901 > > > Repository: qpid-dispatch > > > Description > ------- > > If the client specifies its desire for the ADDRESS-AUTHZ capacbility, the > authorization service, if it supports this, will return a set of permissions > in the properties of the open frame. The properties will have an > address-authz key, whose value is a map of address (or wildcard pattern) to > an array of permissions. The only permissions recognised at present by this > patch are 'send' and 'recv'. > > > Diffs > ----- > > src/policy.c 22cc79f > src/remote_sasl.c e3c969b > tests/CMakeLists.txt 0c6454c > tests/authservice.py PRE-CREATION > tests/system_tests_authz_service_plugin.py PRE-CREATION > > > Diff: https://reviews.apache.org/r/64645/diff/4/ > > > Testing > ------- > > Added new systems tests using proton python based dummy auth service. > > > Thanks, > > Gordon Sim > >
