On 24/08/17 16:38, Alan Conway wrote:
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.
Agreed. SNI, sasl-init and open hostnames should in general all be the same, and this is the realm for cyrus-sasl. However you can only use the SNI or sasl-init hostname for the realm, as you need to get it before authenticating, and the open is only processed after authenticating.
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.
I think the changes required are not large. First the pn_do_init() in sasl.c needs to actually read the hostname from the wire.
There is already a pnx_sasl_get_remote_fqdn() / pni_sasl_set_remote_hostname() field on the sasl object that can store this. At present it seems only to get used on the client side though.
If that gets set, the cyrus-sasl can use it to set the realm on the server side. I agree with Rob, that if the hostname is not present in the sasl-init, then it should fallback to using the SNI if that is available (pn_ssl_get_peer_hostname()).
At present on the client side, proton-c doesn't provide any way to control what is sent in the sasl-init hostname. However it *does* already allow you to set the SNI separately if needed, and defaults to using the hostname which you are using to open a socket. We could use these to set the hostname on sasl-init at some point as well. If there is a need to separately control the sasl-init hostname, that would require a small addition to the public interface. Actually though I think we can get quite far with what is there already.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
