qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [dispatch-router]: authenticating against a remote service
Date Mon, 10 Jul 2017 16:47:49 GMT
On 08/07/17 09:55, Kai wrote:
> On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <gsim@redhat.com> wrote:
>> 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.

Agreed, that would be useful. I think Rob's plugins may already support 
something there, but I didn't test it. The qpid clients needs support 
for some oauth based mechanism at some point.

>> 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.

I agree that keeping the definition of permissions centralized is important.

The authentication plugin I'm proposing could of course also be enhanced 
to follow the approach defined in hono[1], where a token containing all 
the permissions is supplied (using the draft spec for claims based 
security in AMQP) over the connection to the authentication service, and 
this is then used to evaluate what the connection from the client to the 
router is then allowed to do.

I would like to get it in (more or less) its current form though, and 
then evolve it.

The key part of the token handling I think would be the interface 
between the plugin and the router.

I think the first step I want to try and tackle there is the mapping of 
users to groups, allowing the groups of which the authenticated 
principal is a member to be supplied by the authentication service once 
the authentication has completed successfully. That would avoid having 
to specify the users in the policy (which is cumbersome for large 
numbers of users). Hopefully in tackling that I'll start to get a better 
understanding of the relevant code in the router around authz in general.

My initial thought (at least in the short term) was to have a separate 
component push out the necessary permissions to all the routers in a 
network when they change (or when a new router is added). This can also 
involve some transformation of the actual format in which the 
permissions are defined so is quite flexible for short term integration 
(but perhaps less good for out-of-the-box experience).

[1] https://www.eclipse.org/hono/architecture/auth/auth/

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message