sasl mechanisms?

[pierreca]

Hi

taking a look at the sasl-specific portion of the code i'm trying to understand what a client needing a custom sasl mechanism could do.

it looks like the sasl_mechanism interface is synchronous - meaning the init() and next() APIs have to return results and cannot use callbacks/promises, is that correct? in the case where the sasl mechanism relies on external async APIs (for example using a hardware TPM to sign a SASL challenge key with a secret stored in the hardware), how would that work?

also it looks like the PlainClient and AnonymousClient aren't exported? in the case where we want to build a client that supports multiple SASL mechanisms, do we have to rewrite them? or are the sasl_mechanisms collections (the default one and the user-provided one) merged?

[grs]

The idea (which I should be clear is somewhat half-baked) is that new mechanisms could be added by providing a function that returns an object implementing start() and step() methods.

As you say, at present the interface is synchronous. This is not because an asynchronous interface was ruled out, just that the examples I had in mind when writing the code weren't asynchronous (e.g. see below). I agree an asynchronous interface would be better and should not be too difficult a change.

At present the client_mechanisms()/server_mechanisms() functions return objects that have methods for enabling the 'built in' mechanisms (PLAIN, ANONYMOUS & EXTERNAL). You can then also add other mechanisms to that object. Potentially there could be a method to enable all the built in mechs, and maybe have that called based on an argument to the client_mechanisms() call.

[grs]

An example of using an external library to provide a different mechanism (albeit synchronous).

`var container = require('rhea');
var args = require('../options.js').options({
'username': { describe: 'username to connect with'},
'password': { describe: 'password to connect with'},
'p': { alias: 'port', default: 5672, describe: 'port to connect to'}
}).help('help').argv;
var ScramSha1 = require('sasl-scram-sha-1');

function ExtendedClient (username, password) {
this.initial_args = {username: username, password: password};
this.impl = new ScramSha1();
}

ExtendedClient.prototype.start = function() {
return this.impl.response(this.initial_args);
};

ExtendedClient.prototype.step = function(challenge) {
this.impl.challenge(challenge.toString());
return this.impl.response(this.initial_args);
};

container.on('connection_open', function (context) {
console.log('Connected!');
context.connection.close();
});
container.connect({'port':args.port, 'sasl_mechanisms':{'SCRAM-SHA-1':function () { return new ExtendedClient(args.username, args.password)}}});
`

[pierreca]

OK that's kindof what I had figured out - thanks!

[grs]

@pierreca if you want to open another issue to get an async interface for alternative sasl mechanisms, I'll try to address that as soon as I get some time. I appreciate the feedback!

[pierreca]

@grs thanks! no need for now - we're in a place where we use another amqp10 library and are just evaluating the cost to move or support a second option. once we're done investigating maybe we'll come back with requests :)