On 30/04/2008, Ted Ross <[EMAIL PROTECTED]> wrote: > Martin Ritchie wrote: > > > On 28/04/2008, Marnie McCormack <[EMAIL PROTECTED]> wrote: > > > > > > > Thanks Tomas - nice to hear from you ! > > > > > > Regards, > > > > > > Marnie > > > > > > > > > > > > On 4/27/08, Tomas Restrepo <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Marnie, > > > > > > > > > I don't know of any samples though thinking about it I believe it > was > > > > the > > > > > .NET guys that did some work on this stuff. > > > > > > > > > > Anyone know better/more ? > > > > > > > > I did most of the authentication support on the .NET client, > > > > implementing the core SASL support. Currently the .NET client itself > > > > should support Anonymous, CRAM-MD5, Digest, Plain and External > (useful > > > > if eventually implicit SSL with client-side certificates are > supported > > > > by the spec). > > > > > > > > From what I remember, though, the Java client only supported Plain > and > > > > CRAM-MD5 (and one of them had an issue which I do not know if it was > > > > fixed or not). > > > > > > > > -- > > > > Tomas Restrepo > > > > > > > > > > > > > > I've captured this thread here : > > > http://cwiki.apache.org/confluence/display/qpid/Qpid+Interoperability+Documentation#sasl > > > > so it would be good for those better in the know to update the docs. > > Also if someone has a link or two ticks to put a description of > > AMQPLAIN in that would be great. > > > > > For what it's worth, AMQPLAIN is not a SASL mechanism. Furthermore, it's > not mentioned in the 0-10 AMQP spec. > > I think AMQPLAIN used AMQP str8 encoding for the username and password > whereas SASL PLAIN uses null characters to delimit the fields. > > I suggest that we abandon AMQPLAIN and use the standard SASL PLAIN instead. > > -Ted
Sure AMQPLAIN is not an official SASL mechanism but it is a mechanism for authentication. The Java broker/client simply implements it as a SASL plugin to unify authentication. IIRC AMQP 0-8 and 0-9 both specify hence if our clients can run 0-8/0-9 we should maintain that functionality. I'd like to see us standardise on CRAM-MD5, something that doesn't plain text the password of the wire would be good. Sure SSL would be ideal but without any documentation on how the Java SSL Client implementation works (Kevin if your about would love to chat to get some docs on this) then I'll settle for not sending plain text passwords. Cheers Martin -- Martin Ritchie
