qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai <sophokles...@gmail.com>
Subject Re: [dispatch-router]: authenticating against a remote service
Date Sat, 08 Jul 2017 08:55:42 GMT
On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <gsim@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message