On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <[email protected]> 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]. > > That would be a very valuable addition FMPOV.
> 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. > > In fact, I would be interested in supporting token based SASL mechanisms as well. > 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 really would love to see this implemented in Dispatch Router because it would help us (the Eclipse Hono) project tremendously in providing and maintaining a single identity provider. In addition to authentication, are you also thinking about finding a way to delegate the definition and management of authorities associated with the identities? Currently, you need to define the authorities as part of a VHOST's policy. However, it would be desirable FMPOV if it were possible to e.g. keep the authorities either with the identities (e.g. in KeyCloak) or a separate dedicated system and have Dispatch Router "call out" to such a system to verify authorities e.g. during link establishment. Thanks, Kai > [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] > >
