Re: Qpid Dispatch authenticate through ldap, is this possible

[mlange]

Ganesh Murthy wrote
> If I am reading this correctly, you were able to get LDAP to work on the
> router after installing the correct rpms on CentOS? Congratulations.
> Share your steps so I can try this locally.
> 
> Thanks.

I am and I have!

For the RPM: search on rpmfind.net to "cyrus-sasl-ldap", you're bound to
find the one I found.
There may be some overhead, and unneeded stuff I have done and installed, I
tried to filter those out, but can't promise I left none out :-)

Installed software:
yum install openldap openldap-clients compat-openldap
yum install cyrus-sasl-md5 cyrus-sasl-plain cyrus-sasl-scram
yum install python-saslwrapper
yum install cyrus-sasl*

and that other rpm: yum install
/tmp/cyrus-sasl-ldap-2.1.26-21.el7.x86_64.rpm

Next I had to do quite alot of stuff on LDAP; took most of my time to figure
those out.
in cn=config
olcAuthzPolicy: to
olcAuthzRegexp: uid=([^,]*),cn=digest-md5,cn=auth
ldap:///dc=test,o=org??sub?(uid=$1)
olcAuthzRegexp: uid=([^,]*),cn=myrealm,cn=digest-md5,cn=auth
ldap:///dc=test,o=org??sub?(uid=$1)
olcSaslHost: 
olcSaslRealm: 

In olcDatabase=bdb,cn=config:
olcAccess: to dn.children="cn=broker-users,dc=test,o=org" attrs=authzTo by
self auth
olcOverlay=ppolicy -> olcPPolicyHashCleartext: FALSE

Now create a user in cn=broker-users,dc=test,o=org (or whatever suits your
DIT)
uid=qdrouterd
password=qdrouterd (I'm just testing, so this should be fine)
authzTo: dn.regex:cn=[^,]*,ou=broker-users,dc=test,o=org$
authzTo: dn.regex:uid=[^,]*,ou=broker-users,dc=test,o=org$
authzTo: dn.regex:^uid=[^,]*,cn=digest-md5,cn=auth$

(This one got me busy for quite a while, I did this with Apache Directory
Studio, which does not show operational attributes (authzTo is) and
complains about the schema not allowing it. So, not seeing the entries, I
assumed they were not there... they were all the time... but got some
misspellings.

In /etc/sasl2/qdrouterd.conf
pwcheck_method: auxprop
auxprop_plugin: ldapdb
ldapdb_uri: ldap://my.ldap.host
ldapdb_id: qdrouterd
ldapdb_pw: qdrouterd
ldapdb_mech: DIGEST-MD5
log_level: 7

Mind the log-level :-)

And then the listener in qdrouterd:
listener {
name: ontvangst
host: 0.0.0.0
port: 5672
role: normal
authenticatePeer: yes
saslMechanisms: EXTERNAL DIGEST-MD5 PLAIN
}

Now I could do qdstat -a --sasl-user=qdrouterd --sasl-password=qdrouter

I havent yet tried to do more than this, but it shows I'm (almost) on track.




--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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

Re: Qpid Dispatch authenticate through ldap, is this possible

[mlange]

Thanks for that one; seems like a pretty complex way to get things done. In
the mean time I found an rpm for CentOS 7, installed it and went a bit
around things; when I can reproduce what I did (and leave out all the wrong
steps in between) 

It would then be a good idea to compare both solutions and check advantages
/ downsides from one method over the other.
Expect an update soon(ish)!



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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

Re: [Java Broker] Temporary queues ACLs for multiple users

[Keith W]

Hi Tomas

Having had change to reflect on this a bit more, I am contemplating a
change to the existing access-control-plugin which would let you
express rules for objects that the current user has created using a
special pseudo subject 'OWNER'.

It will look something like:

ACL ALLOW-LOG OWNER CONSUME QUEUE

This rule would allow anyone who was the creator of queue (as carried
by the queue's createdBy attribute), to consume from it.

If such an extension existed, would it solve your use-case?  I hope to
have a patch up for you to play with tomorrow.

cheers, Keith.



On 6 April 2018 at 11:25, Vavricka  wrote:
> Hi Keith,
>
> thanks for explanation.
>
> It will be great if you can post skeletal code of ACL module.
>
> Tomas
>
>
> Keith Wall wrote
>> Hi Tomas
>>
>> Unfortunately, Broker-J's access_control plugin is not too good.  It
>> is something we would like to rework when schedules allow.  The
>> current module actually uses an object modal that pre-dates the
>> current one - which leads to user confusion and an ugly adaption layer
>> in the code.  The ACL also assumes AMQP 0-x conventions - publishing
>> only to exchanges and consuming from queues when expressing rules
>> which creates a further wrinkle when using AMQP 1.0.
>>
>> The current module lets you specify rules that match objects using
>> zero or more property qualifiers (e.g. name="foo" or type="fanout"),
>> so it is possible to write rules about named objects in your system
>> and all objects matching certain criteria.   For temporary queues,
>> this doesn't work well as you have discovered.  It is possible to say
>> that user foo can (or cannot) consume from any temporary queue using
>> the temporary=true qualifier, but it is not possible to be specific,
>> but you cannot express a rule that gives users to temporary queues
>> that they have created.
>>
>> The ACL mechanism is pluggable - so it would be possible to write a
>> module that would give the behaviour you need.  You would need to look
>> at the AccessControlProvider and AccessControl interfaces.  The Broker
>> supports one or more access control providers.  It consults each
>> AccessControlProvider in order until one make a decision that is not
>> DEFER.  So you could hopefully write a simple ACL module that you give
>> you the additional behaviour you need and fallback on access_control
>> plugin for everything else.  If you want to explore this route, I
>> could share some skeletal code to help get you started.
>>
>> Turning to your last point, when using AMQP 1.0 and wishing to
>> permission publishing directly to queues, as access_control plugin
>> knows only AMQP 0-x conventions you have to permission the default
>> exchange.
>>
>> ACL ALLOW-LOG foo PUBLISH EXCHANGE name="" routingKey="queueName"
>>
>> Hope this helps.
>>
>> Keith
>>
>> On 5 April 2018 at 14:46, Vavricka 
>
>> vavricka.tomas@
>
>>  wrote:
>>> Hi,
>>>
>>> I am trying to get working temporary queues on Java Broker. Each user
>>> should
>>> have access only to queue which he created.
>>>
>>> ACL rights:
>>>
>>> ACL ALLOW-LOG user1 ACCESS VIRTUALHOST
>>> ACL ALLOW-LOG user1 CREATE QUEUE temporary="true" owner="user1"
>>> ACL ALLOW-LOG user1 CONSUME QUEUE temporary="true" owner="user1"
>>>
>>> ACL ALLOW-LOG user2 ACCESS VIRTUALHOST
>>> ACL ALLOW-LOG user2 CREATE QUEUE temporary="true" owner="user2"
>>> ACL ALLOW-LOG user2 CONSUME QUEUE temporary="true" owner="user2"
>>>
>>> I successfully create temporary queue by JMS method "TemporaryQueue
>>> temporaryQueue = session.createTemporaryQueue()", queue is correctly
>>> created
>>> on broker, but owner is not set in webgui (however createdBy and
>>> lastUpdatedBy in JSON is correctly set to corresponding user).
>>>
>>> When I try to create consumer by "MessageConsumer consumer =
>>> session.createConsumer(temporaryQueue)", I get "Permission CREATE is
>>> denied
>>> for : Consumer ...". When owner is not set in CONSUME ACL I can create
>>> consumer without error, but both users can consume same queue. Is there
>>> any
>>> different way to distinguish temporary queues, so one user cannot read
>>> other
>>> user messages?
>>>
>>> Another issue is I cannot sent messages directly to temporary queue. When
>>> I
>>> try to send message I get error "Permission PERFORM_ACTION(publish) is
>>> denied for : Queue 'TempQueueba2f889e-f95c-49d4-8c15-023e62666320'". We
>>> could utilize sending messages directly to queue, because we cannot
>>> dynamically create exchange binding by REST API. Or is there any way to
>>> set
>>> bindings by JMS?
>>>
>>> Java Broker 7.0.3
>>> Qpid JMS client 0.31.0
>>>
>>> Tomas
>>>
>>>
>>>
>>> --
>>> Sent from:
>>> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>>
>>> -
>>> To unsubscribe, e-mail:
>
>> users-unsubscribe@.apache
>
>>> For additional commands, e-mail:
>
>> users-help@.apache
>
>>>
>>
>> 

Re: Qpid Dispatch authenticate through ldap, is this possible

[Ganesh Murthy]

On Wed, Apr 11, 2018 at 10:32 AM, mlange  wrote:

> Thanks for that one; seems like a pretty complex way to get things done. In
> the mean time I found an rpm for CentOS 7, installed it and went a bit
> around things; when I can reproduce what I did (and leave out all the wrong
> steps in between)
>
If I am reading this correctly, you were able to get LDAP to work on the
router after installing the correct rpms on CentOS? Congratulations.
Share your steps so I can try this locally.

Thanks.


>
> It would then be a good idea to compare both solutions and check advantages
> / downsides from one method over the other.
> Expect an update soon(ish)!
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Qpid dispatch unstable inter-router connections

[Marcel Meulemans]

Hi all,

I am running a three node fully connected mesh of dispatch routers with
1 attached clients and I am seeing some unstable inter-router
connections (I am sending around 1000 message per second through the
network). The inter-router connections fail every so many seconds with the
message: Connection to router-2:55672 failed: amqp:session:invalid-field
sequencing error, expected delivery-id 7, got 6

I am not sure if this is to be expected / unexpected or that I have a
faulty configuration.

The routers are connected as follows: router-0 -> router-1, router-0 ->
router-2, router-1 -> router-2
Attached are my qdrouter.conf (from one of the routers) and a log snippet
from router-0 at debug level from connection drop to connection
re-established to connection drop again.
Versions: qpid-dispatch@1.0.1-rc1, qpid-proton@0.20.0

Hope someone can help.

Cheers,
Marcel
2018-04-11 18:47:04.801720 + ROUTER_LS (info) Link to Neighbor Router Lost - link_tag=0
2018-04-11 18:47:05.785203 + ROUTER_LS (info) Computed next hops: {}
2018-04-11 18:47:05.785281 + ROUTER_LS (info) Computed costs: {}
2018-04-11 18:47:05.785307 + ROUTER_LS (info) Computed valid origins: {}
2018-04-11 18:47:05.785337 + ROUTER_LS (info) Computed radius: 0
2018-04-11 18:47:09.908855 + ROUTER_CORE (debug) Delivery incref:dlv:7f0bac158850 rc:1 qdr_forward_deliver_CT - add to undelivered list
2018-04-11 18:47:09.908977 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e02e50 rc:1 qdr_forward_deliver_CT - add to undelivered list
2018-04-11 18:47:09.909109 + ROUTER_CORE (debug) Delivery decref:dlv:7f0bac158850 rc:0 qdr_link_process_deliveries - remove from undelivered list
2018-04-11 18:47:09.909246 + ROUTER_CORE (debug) Delivery decref:dlv:7f0ba7e02e50 rc:0 qdr_link_process_deliveries - remove from undelivered list
2018-04-11 18:47:10.470544 + ROUTER_CORE (debug) Delivery incref:dlv:55b497cb1c10 rc:1 qdr_link_deliver_to - newly created delivery, add to action list
2018-04-11 18:47:10.470618 + ROUTER_CORE (debug) Delivery incref:dlv:55b497cb1c10 rc:2 qdr_link_deliver_to - protect returned value
2018-04-11 18:47:10.470635 + ROUTER_CORE (debug) Delivery decref:dlv:55b497cb1c10 rc:1 release protection of return from deliver
2018-04-11 18:47:10.470723 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e03dd0 rc:1 qdr_link_deliver_to - newly created delivery, add to action list
2018-04-11 18:47:10.470734 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e03dd0 rc:2 qdr_link_deliver_to - protect returned value
2018-04-11 18:47:10.470759 + ROUTER_CORE (debug) Delivery decref:dlv:7f0ba7e03dd0 rc:1 release protection of return from deliver
2018-04-11 18:47:10.470790 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e05cd0 rc:1 qdr_link_deliver_to - newly created delivery, add to action list
2018-04-11 18:47:10.470798 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e05cd0 rc:2 qdr_link_deliver_to - protect returned value
2018-04-11 18:47:10.470806 + ROUTER_CORE (debug) Delivery decref:dlv:7f0ba7e05cd0 rc:1 release protection of return from deliver
2018-04-11 18:47:10.470948 + ROUTER_CORE (debug) Delivery decref_CT: dlv:55b497cb1c10 rc:0 qdr_link_forward_CT - removed from action (2)
2018-04-11 18:47:10.476199 + ROUTER_CORE (debug) Delivery decref_CT: dlv:7f0ba7e03dd0 rc:0 qdr_link_forward_CT - removed from action (2)
2018-04-11 18:47:10.476262 + ROUTER_CORE (debug) Delivery decref_CT: dlv:7f0ba7e05cd0 rc:0 qdr_link_forward_CT - removed from action (2)
2018-04-11 18:47:12.472096 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e05e50 rc:1 qdr_link_deliver_to - newly created delivery, add to action list
2018-04-11 18:47:12.472168 + ROUTER_CORE (debug) Delivery incref:dlv:7f0ba7e05e50 rc:2 qdr_link_deliver_to - protect returned value
2018-04-11 18:47:12.472225 + ROUTER_CORE (debug) Delivery decref_CT: dlv:7f0ba7e05e50 rc:1 qdr_link_forward_CT - removed from action (2)
2018-04-11 18:47:12.472241 + ROUTER_CORE (debug) Delivery decref:dlv:7f0ba7e05e50 rc:0 release protection of return from deliver
2018-04-11 18:47:14.471905 + ROUTER_CORE (debug) Delivery incref:dlv:7f0bac15a610 rc:1 qdr_link_deliver_to - newly created delivery, add to action list
2018-04-11 18:47:14.471968 + ROUTER_CORE (debug) Delivery incref:dlv:7f0bac15a610 rc:2 qdr_link_deliver_to - protect returned value
2018-04-11 18:47:14.472001 + ROUTER_CORE (debug) Delivery decref_CT: dlv:7f0bac15a610 rc:1 qdr_link_forward_CT - removed from action (2)
2018-04-11 18:47:14.472015 + ROUTER_CORE (debug) Delivery decref:dlv:7f0bac15a610 rc:0 release protection of return from deliver
2018-04-11 18:47:14.921856 + ROUTER_LS (info) Computed next hops: {'router-2': 'router-2', 'router-1': 'router-2'}
2018-04-11 18:47:14.921941 + ROUTER_LS (info) Computed costs: {'router-2': 1, 'router-1': 2}
2018-04-11 18:47:14.921970 + 

Re: Qpid dispatch unstable inter-router connections

[Ganesh Murthy]

On Wed, Apr 11, 2018 at 3:14 PM, Marcel Meulemans <
m.meulem...@tkhinnovations.com> wrote:

> Hi all,
>
> I am running a three node fully connected mesh of dispatch routers with
> 1 attached clients and I am seeing some unstable inter-router
> connections (I am sending around 1000 message per second through the
> network). The inter-router connections fail every so many seconds with the
> message: Connection to router-2:55672 failed: amqp:session:invalid-field
> sequencing error, expected delivery-id 7, got 6
>
Is it complaining about the same delivery id (7 got 6) every time in the
sequencing error  ? I am hoping not.

>
> I am not sure if this is to be expected / unexpected or that I have a
> faulty configuration.
>
> The routers are connected as follows: router-0 -> router-1, router-0 ->
> router-2, router-1 -> router-2
> Attached are my qdrouter.conf (from one of the routers) and a log snippet
> from router-0 at debug level from connection drop to connection
> re-established to connection drop again.
> Versions: qpid-dispatch@1.0.1-rc1, qpid-proton@0.20.0
>
> Hope someone can help.
>
> Cheers,
> Marcel
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

Re: Qpid dispatch unstable inter-router connections

[Matthieu Simonin]

Hi Marcel,

Funny coïncidence ;)

I ran also some load tests lately, I haven't seen this behaviour using
the same 3 fully connected nodes topology.

I was using qpid-dispatch@1.0.1 and qpid-proton@0.21

My workload consisted in sending RPCs[1] through the mesh.
- 10K clients / 20 servers
- clients send at 1msg/s that leads to 10K msg/s on the bus for 
"fire-and-forget" RPCs and thus 20K msg/s for "request/reply" style RPCs.

Note that the above 
 - uses small message size (approx 1KB)
 - the load lasted only 5 min but was repeated with different number of clients.
Thus routers were up for 3 hours.
 - clients connections were balanced on the 3 routers. 

I'm afraid I can't help further but I'll be although interested in the 
discussion.

Best,

[1]: https://docs.openstack.org/oslo.messaging/latest/

Matthieu



- Mail original -
> De: "Marcel Meulemans" 
> À: "users" 
> Envoyé: Mercredi 11 Avril 2018 21:14:39
> Objet: Qpid dispatch unstable inter-router connections

> Hi all,
> 
> I am running a three node fully connected mesh of dispatch routers with
> 1 attached clients and I am seeing some unstable inter-router
> connections (I am sending around 1000 message per second through the
> network). The inter-router connections fail every so many seconds with the
> message: Connection to router-2:55672 failed: amqp:session:invalid-field
> sequencing error, expected delivery-id 7, got 6
> 
> I am not sure if this is to be expected / unexpected or that I have a
> faulty configuration.
> 
> The routers are connected as follows: router-0 -> router-1, router-0 ->
> router-2, router-1 -> router-2
> Attached are my qdrouter.conf (from one of the routers) and a log snippet
> from router-0 at debug level from connection drop to connection
> re-established to connection drop again.
> Versions: qpid-dispatch@1.0.1-rc1, qpid-proton@0.20.0
> 
> Hope someone can help.
> 
> Cheers,
> Marcel
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org

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