On 21/06/17 20:22, Gordon Sim wrote:
I would like to be able to have the router (or a network of routers)
configured to authenticate against a separate service. In my case I
would like to use keycloak[1].
As the router uses proton-c for the sasl layer, the first requirement is
that the sasl layer be runtime configurable in proton-c to allow an
alternative to cyrus-sasl to be set. Andrew has committed a solution to
this (see PROTON-1500).
I have a patch for the router[2], that relies on the solution to
PROTON-1500, and adds the ability to delegate the authentication to a
remote service. This works by relaying the AMQP SASL frames. That
mechanism allows us to use SCRAM-SHA-1 (as well as PLAIN). In fact the
set of mechanisms is controlled by the authentication service itself.
I should note that this design was Rob Godfrey's idea, and he also
created plugins[3] for keycloak that support the SASL exchange from the
core AMQP specification. Of course, as all it requires is support for
the AMQP core protocol SASL exchange (up to and including an AMQP open
frame), it would be possible to add support to other authentication
services and you can even use an existing AMQP server (a broker or a
custom proton-c based service for example).
I'd like to propose that this alternate approach to authentication be
included in the next release as an experimental feature. At present it
is exposed through two config fields on the listener: authService, which
is the host:port to connect to, and authSslProfile which is the SSL
config to use when connecting. I plan to think how this might be
improved to (a) have an approach that could be used for other
authentication approaches and (b) more clearly delineate the
experimental feature from the well established core set of fields in the
listener.
I have updated the patch at [2] with a revised approach to the config
that I think meets these two objectives (a and b above).
It defines a single saslPlugin field in the listener, which then refers
to the name of another element in the config. At present the only
suitable element is one of type authServicePlugin (in which the other
fields provide the needed configuration). However, in future, should any
other psasl plugin be defined, it can specify a different schema element
for itself and tie that to the listener through the same saslPlugin
field. (The qd_config_sasl_plugin_t would then be converted to contain a
discriminated union of the different sets of config for the different
plugins).
Both the saslPlugin field and the new element are marked experimental
and would be subject to change in the future.
[1] http://www.keycloak.org/
[2] https://reviews.apache.org/r/59352/
[3] https://github.com/rgodfrey/keycloakplugins/tree/master/src/main
---------------------------------------------------------------------
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]
