Bug 604149

I'm not sure that I clearly understand the use case. 

You say:

> which leads sometimes to very difficult situation, because
> mechanism picked by cyrus-sasl is not always suitable.

What are the situations in which the mechanmism picked by
cyrus-sasl is not suitable? 

As I understand it, cyrus-sasl always picks the most secure
mechanism that is supported by both the server and the client. If
the mechanism requires a password, it can be specified in the
connection URL. The other mechanisms do not affect the command
line of these tools.

Are you thinking of a scenario where a test environment sets up a
broker that supports many mechanisms, then tests each mechanism?
Is this only for testing, or is this something that you would
envision someone actually using in a production environment?

This defect requests possibility to select authentication mechanism for underlying SASL layer.

There are couple of situations when forcing the specific authentication mechanism is the only way to get management data.

Lately I have been reviewing a GSSAPI client - broker scenario and in situation when kerberos setup was not correct or tickets were intentionally destroyed to prove that client does not succeeds the authentication qpid-tools fail to execute the operation.

These two scenarios highlight need of adding possibility to select the authentication mechanism for qpid-tools.

As I understand it, all that is needed is the ability to select the mechanism by name, as in perftest?

Done, upstream in revision 1051700.

The following revisions are related:

Revision: 1055267

Allow any SASL mechanism to be specified in command line options.

Previously used a fixed list of SASL mechanisms.  

Revision: 1055632

Fixes typo in findById function declaration.

Some qpid-tools python clients have possibility to choose authentication mechanism but others do not; see lists bellow.

Tools with possibility to choose the authentication mechanism (via the "sasl-mechanism" option):
qpid-config
qpid-queue-stats
qpid-route (via the "client-sasl-mechanism" option)
qpid-stat
qpid-printevents

Tools with authentication option but without possibility to choose authentication mechanism:
qpid-tool
qmf-tool 

Tools without authentication option:
qpid-cluster
qpid-cluster-store

I'm unclear about qpid-cluster-store case. I guess this tool does not create broker connection and thus should not have sasl-mechanism switch, right?

Tested packages: qpid-cpp - 0.10.3 on RHEL 5.6 / 6.1 i[36]86/ x86_64 

-->ASSIGNED

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Qpid-tool's python clients (such as qpid-config, qpid-queue-stats, qpid-route, qpid-stat and qpid-printevents) are now able to select the mechanism used by them for authentication.

My question is still pending, raising NEEDINFO back.

https://bugzilla.redhat.com/show_bug.cgi?id=710429 raised to cover the absence of the feature in the remaining three tools (qpid-cluster-store is a separate case as it does not connect to a broker and therefore does not authenticate at all).

Technical note can be viewed in the release notes for 2.0 at the documentation stage here:

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2.0/html-single/MRG_Release_Notes/index.html#tabl-MRG_Release_Notes-CONSOLE_Update_Notes-CONSOLE_Update_Notes

Hi Gordon,

thank you for answer my question and for creating the additional bug.

The "qpid-tools" for which the possibility to choose the authentication mechanism is relevant, except "qpid-cluster", "qpid-tool" and "qmf-tool" (see bug 710429) can choose the authentication mechanism.

--> VERIFIED