On Thu, 2017-08-24 at 08:17 +0100, Gordon Sim wrote: > On 24/08/17 05:53, Andrew Stitcher wrote: > > I think connection bound is after authentication - unless I'm forgetting > > things due to vacation all events are after authentication. > > Having been poking around in this area recently, I can confirm that > CONNECTION_BOUND will occur *before* the authentication. > > > 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) > 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. > 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]
