On 08/07/17 09:55, Kai wrote:
On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
