[cap-talk] caps tried and rejected for AMQP

[Ben Hood]

Hi,

If you're really interested in the real reason why after consideration  
ACLs got the nod ahead of caps in RabbitMQ, I suggest that you ask  
this question on the Rabbit mailing list. I can only give you my  
biased view because I was the one who proposed caps in Rabbit in the  
first place.

Maybe a little context might help:

The 0-8 AMQP spec originally mandated a conceptually flawed ACL  
mechanism in the protocol. Rabbit committed the schoolboy error of  
treating this as gospel and actually implemented it, only to find out  
that the other implementors decided to abstain. Hence the working  
group dropped ACLs from the protocol. So we deleted that code from our  
source tree.

In the meantime, many administrators of Rabbit were complaining that  
they had no fine grained mechanism to control access to the broker. In  
response to this, we began to devise a proprietary ACL mechanism  
orthogonal to the protocol. As this was happening, I began to research  
and protoype the use of caps to acheive the same end. The result of  
this was some running code in the broker and the article that is the  
subject of this thread.

IMHO the main disadvantages of the caps approach are:

- It would most probably require a minor revision to the protocol to  
become compliant;
- You'd have to augment every client library that wanted to take  
advantage of access control - only a few clients are actually  
maintained by Rabbit;
- No users were asking for something like caps - they just wanted ACLs;
- The conceptual overhead may have been too great for a significant  
number of users;
- Some intelligent people remained unconvinced about the merits of caps;
- It would have confused a lot of sysadmins - they generally prefer  
ACLs and they were the ones asking to have access control put back;

Having said that, there were some positive touchpoints:

- ACLs require that the broker implementors decide a priori what  
catagories of access control are required rather than deferring this  
to the application developers;
- Caps allow arbitrarily fine access control (see this thread for a  
relevant example: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-August/004389.html 
);
- Caps facilate distributed access control;
- Users can define their own access semantics a posteriori;
- (Personally) I like the meta-circularity it would bring;

If you were to design it carefully, you could choose any number of  
languages to express caps and still remain protocol compliant. I used  
AMQP as the DSL for caps in my prototype, but I could have defined my  
own language or even gone for something Turing complete.

Furthermore, I am a complete n00b when it comes to caps - I may well  
have missed the whole point in my prototype - nobody has ever  
commented on the implementation, so it's hard to tell whether it makes  
sense or not.

I guess that if anybody in the caps community did want evangelize it's  
adoption in Rabbit, the best thing to do IMHO is to provide us with a  
workable concept of how to layer ACLs on top of capabilities so that  
you have the best of both worlds. Bear in mind that whilst the Rabbit  
team is receptive to new ideas, we are run off our feet implementing  
other features, so working code will speak louder than anything else.

I hope that this is helpful,

Cheers,

Ben