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. -- 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] > >
