[dispatch-router]: authenticating against a remote service

[Gordon Sim <gs...@redhat.com>]

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.

[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

Re: [dispatch-router]: authenticating against a remote service

[Gordon Sim <gs...@redhat.com>]

On 08/07/17 09:55, Kai wrote:
> On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <gs...@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

Re: [dispatch-router]: authenticating against a remote service

[Kai <so...@gmail.com>]

On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <gs...@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
>
>

Re: [dispatch-router]: authenticating against a remote service

[Gordon Sim <gs...@redhat.com>]

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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 


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