[dispatch-router]: authenticating against a remote service

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[dispatch-router]: authenticating against a remote service

Gordon Sim
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kai Hudalla
On Wed, Jun 21, 2017 at 9:22 PM Gordon Sim <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gordon Sim
In reply to this post by Gordon Sim
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...