You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Hudalla Kai (INST/ECS4)" <ka...@bosch-si.com> on 2018/10/18 09:04:13 UTC
Changes to auth plugin in Dispatch Router
Hi,
I have been successfully using the (experimental) SASL auth plugin feature with
Dispatch Router 1.1.0. I had implemented an auth service and configured the
router to use it for authenticating clients and authorizing requests to establish
links.
I have now tried to use the same auth server with Dispatch Router 1.4.0 but was
not able to successfully authorize a client opening two receiver links anymore.
I have seen the changes made to the "authenticated-identity" property that the
router expects with 1.4.0 and have modified my service accordingly.
Authentication seems to work well but the router won't authorize the client's
attempt to open the links anymore.
Here is the log of the router:
2018-10-18 08:54:45.505399 +0000 SERVER (info) enabling remote authentication
service 10.56.84.13:45672
2018-10-18 08:54:45.505466 +0000 SERVER (info) [3]: Accepted connection to
0.0.0.0:5672 from 172.17.0.1:34016
2018-10-18 08:54:45.657490 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_CONNECTION_INIT
2018-10-18 08:54:45.657556 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_CONNECTION_LOCAL_OPEN
2018-10-18 08:54:45.657586 +0000 AUTHSERVICE (debug) Handling connection bound
event for authentication service connection
2018-10-18 08:54:45.668285 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_CONNECTION_WAKE
2018-10-18 08:54:45.668367 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT
2018-10-18 08:54:45.674239 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT
2018-10-18 08:54:45.678036 +0000 AUTHSERVICE (debug) authentication against
service complete; closing connection
2018-10-18 08:54:45.678095 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT
2018-10-18 08:54:45.678113 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_CONNECTION_LOCAL_CLOSE
2018-10-18 08:54:45.678128 +0000 AUTHSERVICE (info) authenticated as
consumer@HONO
2018-10-18 08:54:45.678174 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT
2018-10-18 08:54:45.678186 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT_TAIL_CLOSED
2018-10-18 08:54:45.678194 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT_ERROR
2018-10-18 08:54:45.678202 +0000 AUTHSERVICE (debug) Ignoring event for
authentication service connection: PN_TRANSPORT_HEAD_CLOSED
2018-10-18 08:54:45.678211 +0000 AUTHSERVICE (debug) disconnected from
authentication service
2018-10-18 08:54:45.724158 +0000 POLICY (info) [3]: DENY AMQP Attach receiver
link 'event/DEFAULT_TENANT' for user 'consumer@HONO', rhost '172.17.0.1', vhost
'hono' based on link source name
2018-10-18 08:54:45.724209 +0000 POLICY (info) [3]: DENY AMQP Attach receiver
link 'telemetry/DEFAULT_TENANT' for user 'consumer@HONO', rhost '172.17.0.1',
vhost 'hono' based on link source name
2018-10-18 08:54:45.768878 +0000 SERVER (info) [3]: Connection from
172.17.0.1:34016 (to 0.0.0.0:5672) failed: amqp:connection:framing-error
connection aborted
2018-10-18 08:54:45.769075 +0000 POLICY (debug) Connection '172.17.0.1:34016'
closed with resources n_sessions=1, n_senders=0, n_receivers=0. nConnections= 0.
And here is the router configuration file I am using:
[
["router", {
"id": "Hono.Example.Router",
"mode": "standalone",
"workerThreads": 3
}],
["authServicePlugin", {
"name": "Hono Auth",
"host": "10.56.84.13",
"port": 45672
}],
["listener", {
"host": "0.0.0.0",
"port": 5672,
"authenticatePeer": true,
"saslMechanisms": "PLAIN",
"saslPlugin": "Hono Auth"
}],
["policy", {
"maxConnections": 1000,
"enableVhostPolicy": true,
"defaultVhost": "hono"
}],
["vhost", {
"hostname": "hono",
"maxConnections": 500,
"maxConnectionsPerUser": 20,
"maxConnectionsPerHost": 10,
"allowUnknownUser": true,
"groups": {
"$default": {
"remoteHosts": "*"
}
}
}],
["log", {
"module": "DEFAULT",
"enable": "debug+"
}]
]
Have there been any additional changes to the format that the router expects the
authorities being conveyed in the auth server's open frame's properties?
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
Dr. Stefan Ferber, Michael Hahn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Changes to auth plugin in Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 18/10/18 21:56, Gordon Sim wrote:
> The fix is straightforward. I'll update the tests to ensure we don't
> regress on this aspect again.
https://issues.apache.org/jira/browse/DISPATCH-1149, fixed on master
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Changes to auth plugin in Dispatch Router
Posted by Ganesh Murthy <gm...@redhat.com>.
On Fri, Oct 19, 2018 at 6:04 AM Hudalla Kai (INST/ECS4) <
kai.hudalla@bosch-si.com> wrote:
> On Thu, 2018-10-18 at 21:56 +0100, Gordon Sim wrote:
> > On 18/10/18 15:07, Hudalla Kai (INST/ECS4) wrote:
> > > I am supplying them from the auth service in the same format that
> worked in
> > > 1.1.0.
> >
> > This is not a result of any change in the auth plugin itself. Since
> > 1.2.0, setting the valid sources and targets on the policy_settings of
> > the connection no longer override the policy in the config file.
> >
>
> Thanks for the info, Gordon. We will then need to wait for 1.5.0, I guess
> ...
>
Since this is an important fix, I am going to put out a vote shortly for
1.4.1 which will contain this fix.
Thanks.
>
> > The fix is straightforward. I'll update the tests to ensure we don't
> > regress on this aspect again.
> >
> > [This was (I believe) an unintentional result of
> >
>
> https://github.com/apache/qpid-dispatch/commit/dc981ecc6cf31d8c605e84703a589553281281c2#diff-adc0a0fef2880417cb24cb072363fc29
> >
> > which reverted the necessary change made in
> >
>
> https://github.com/apache/qpid-dispatch/commit/eed8bb65497b23e512072f5ea9fefd8ed73921ef#diff-adc0a0fef2880417cb24cb072363fc29
> > ]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
Re: Changes to auth plugin in Dispatch Router
Posted by "Hudalla Kai (INST/ECS4)" <ka...@bosch-si.com>.
On Thu, 2018-10-18 at 21:56 +0100, Gordon Sim wrote:
> On 18/10/18 15:07, Hudalla Kai (INST/ECS4) wrote:
> > I am supplying them from the auth service in the same format that worked in
> > 1.1.0.
>
> This is not a result of any change in the auth plugin itself. Since
> 1.2.0, setting the valid sources and targets on the policy_settings of
> the connection no longer override the policy in the config file.
>
Thanks for the info, Gordon. We will then need to wait for 1.5.0, I guess ...
> The fix is straightforward. I'll update the tests to ensure we don't
> regress on this aspect again.
>
> [This was (I believe) an unintentional result of
>
https://github.com/apache/qpid-dispatch/commit/dc981ecc6cf31d8c605e84703a589553281281c2#diff-adc0a0fef2880417cb24cb072363fc29
>
> which reverted the necessary change made in
>
https://github.com/apache/qpid-dispatch/commit/eed8bb65497b23e512072f5ea9fefd8ed73921ef#diff-adc0a0fef2880417cb24cb072363fc29
> ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: Changes to auth plugin in Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 18/10/18 15:07, Hudalla Kai (INST/ECS4) wrote:
> I am supplying them from the auth service in the same format that worked in
> 1.1.0.
This is not a result of any change in the auth plugin itself. Since
1.2.0, setting the valid sources and targets on the policy_settings of
the connection no longer override the policy in the config file.
The fix is straightforward. I'll update the tests to ensure we don't
regress on this aspect again.
[This was (I believe) an unintentional result of
https://github.com/apache/qpid-dispatch/commit/dc981ecc6cf31d8c605e84703a589553281281c2#diff-adc0a0fef2880417cb24cb072363fc29
which reverted the necessary change made in
https://github.com/apache/qpid-dispatch/commit/eed8bb65497b23e512072f5ea9fefd8ed73921ef#diff-adc0a0fef2880417cb24cb072363fc29]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Changes to auth plugin in Dispatch Router
Posted by "Hudalla Kai (INST/ECS4)" <ka...@bosch-si.com>.
On Thu, 2018-10-18 at 14:43 +0100, Gordon Sim wrote:
> On 18/10/18 10:04, Hudalla Kai (INST/ECS4) wrote:
> > here is the router configuration file I am using:
> >
> > [
> > ["router", {
> > "id": "Hono.Example.Router",
> > "mode": "standalone",
> > "workerThreads": 3
> > }],
> >
> > ["authServicePlugin", {
> > "name": "Hono Auth",
> > "host": "10.56.84.13",
> > "port": 45672
> > }],
> >
> > ["listener", {
> > "host": "0.0.0.0",
> > "port": 5672,
> > "authenticatePeer": true,
> > "saslMechanisms": "PLAIN",
> > "saslPlugin": "Hono Auth"
> > }],
> >
> > ["policy", {
> > "maxConnections": 1000,
> > "enableVhostPolicy": true,
> > "defaultVhost": "hono"
> > }],
> >
> > ["vhost", {
> > "hostname": "hono",
> > "maxConnections": 500,
> > "maxConnectionsPerUser": 20,
> > "maxConnectionsPerHost": 10,
> > "allowUnknownUser": true,
> > "groups": {
> > "$default": {
> > "remoteHosts": "*"
> > }
> > }
> >
> >
> > ["log", {
> > "module": "DEFAULT",
> > "enable": "debug+"
> > }]
> > ]
> >
> > Have there been any additional changes to the format that the router expects
> > the
> > authorities being conveyed in the auth server's open frame's properties?
>
> No, none that I can see since 1.3.0. I ran 1.3.0 against a dummy auth
> service that returned the username directly against the
> authenticated-identity option, as the router expected pre-1.4.0 and I
> still get the link denied.
>
> If I add "sources": "*", targets: "*" to the $default group in the hono
> vhost policy, it works.
>
> Are you supplying the sources/targets from your auth service? Or relying
> only on the rules in the conf file?
>
I am supplying them from the auth service in the same format that worked in
1.1.0.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: Changes to auth plugin in Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 18/10/18 10:04, Hudalla Kai (INST/ECS4) wrote:
> here is the router configuration file I am using:
>
> [
> ["router", {
> "id": "Hono.Example.Router",
> "mode": "standalone",
> "workerThreads": 3
> }],
>
> ["authServicePlugin", {
> "name": "Hono Auth",
> "host": "10.56.84.13",
> "port": 45672
> }],
>
> ["listener", {
> "host": "0.0.0.0",
> "port": 5672,
> "authenticatePeer": true,
> "saslMechanisms": "PLAIN",
> "saslPlugin": "Hono Auth"
> }],
>
> ["policy", {
> "maxConnections": 1000,
> "enableVhostPolicy": true,
> "defaultVhost": "hono"
> }],
>
> ["vhost", {
> "hostname": "hono",
> "maxConnections": 500,
> "maxConnectionsPerUser": 20,
> "maxConnectionsPerHost": 10,
> "allowUnknownUser": true,
> "groups": {
> "$default": {
> "remoteHosts": "*"
> }
> }
> }],
>
> ["log", {
> "module": "DEFAULT",
> "enable": "debug+"
> }]
> ]
>
> Have there been any additional changes to the format that the router expects the
> authorities being conveyed in the auth server's open frame's properties?
No, none that I can see since 1.3.0. I ran 1.3.0 against a dummy auth
service that returned the username directly against the
authenticated-identity option, as the router expected pre-1.4.0 and I
still get the link denied.
If I add "sources": "*", targets: "*" to the $default group in the hono
vhost policy, it works.
Are you supplying the sources/targets from your auth service? Or relying
only on the rules in the conf file?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org