On Thu, 2017-08-24 at 16:13 +0200, Rob Godfrey wrote: > On 24 August 2017 at 15:06, Gordon Sim <[email protected]> wrote: > > > On 24/08/17 13:42, Alan Conway wrote: > > > > > On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote: > > > > > > > On Tue, Aug 22, 2017, at 11:15 AM, Alan Conway wrote: > > > > > > > > > > > Reading the SASL docs I think we also need to allow SASL realm to be > > > > > > set on a per-connection basis, in CONNECTION_BOUND - and expose > > > > > > that in > > > > > > all bindings. This is because the realm may be set by the server > > > > > > based > > > > > > on incoming vhost. CONNECTION_BOUND is the only point where we a) > > > > > > have > > > > > > the incoming vhost and b) authentication is not yet done, so it > > > > > > seems > > > > > > the right place. I think it's a simple setter on the SASL object, > > > > > > any > > > > > > other ideas? > > > > > > > > > > > > > > I'm not sure if I understand this right. When you say 'vhost', what do > > > > you mean? The hostname in sasl-init? > > > > > > > > > > The AMQP open hostname (which is normally the hostname passed to sasl- > > > init I think) > > > > > > > The open is only processed after successful sasl authentication though. I > > agree that they should most likely be the same value, but I think the > > sasl-init should be used to determine the vhost/realm as far as auth goes. > > > I think in the case of a TLS connection, where there is an available SNI > and *no* sasl-init hostname then I would think that you should use the SNI > name for the host/realm. This is in-line with what the AMQP spec appears > to be trying to say (in the normal course of events the sasl-init hostname > should not be different to the SNI hostname or the open hostname). > Obviously if sasl-init provides a hostname you should use that. In the > case where your server does not provide vhosts/realms then you should > probably always ignore what is in sasl-init hostname / SNI.
What I'm getting at is if we have an AMQP server that acts as multiple hosts, then you probably want to co-ordinate between whatever you regard as the 'host' (SNI, SASL, AMQP, please God let them be the same) and SASL realms. The same user might exist on different 'hosts' with different credentials. The whole point of SASL realms appears to be to support that, but you can't do it with proton. > > -- Rob > > > > > > If so, the particular sasl mechanism in use has access to that and can > > > > use it to set the realm (which I am assuming is a term related to the > > > > sasl impl, e.g. the cyrus-sasl library?). > > > > > > > > > > Right, but a multi-host application might want to make descions based > > > on the AMQP host *before* the SASL process starts, e.g. to choose the > > > realm for authentication. SASL mech has access to hostname but has no > > > notion of mapping that to a realm. > > > > > > From sasl.h: > > > > > > * A single server may support multiple realms. If the > > > * server knows the realm at connection creation time (e.g., a server > > > * with multiple IP addresses tightly binds one address to a specific > > > * realm) then that realm must be passed in the user_realm field of > > > * the sasl_server_new call. > > > > > > Currently we offer no way to do that. > > > > > > > The cyrus sasl impl could take the sasl-init hostname and use that as the > > realm. The sasl-plugin interface already exposes that hostname, so all that > > is required there is actually the change to the cyrus impl (and then of > > course a way for clients to actually set the hostname). > > > > > > I raised https://issues.apache.org/jira/browse/PROTON-1542 for allowing > > > > clients to control the value of hostname that is sent out in sasl-init. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
