Re: SASL negotiation w/ EXTERNAL
On Wed, 2015-09-09 at 15:57 +, Clemens Vasters wrote: > Hi Andrew, > > I agree that the server should only offer EXTERNAL when the client > has presented a valid cert. > > We have the case that we still want to use PLAIN or ANONYMOUS even in > that case, however, since we'll want to use a particular permissions > -bound key not representable by the cert, or differentiated per-node > (link) access control with the AMQP claims-based model, This is a new thing to me - do you have a pointer to documentationa about the "claims-based" (access control?) model. > So I/we would really like to have an override hook for this. The > flags seem cheap; apn_messenger_set_allowed_sasl_mechs() > function would be just as cheap. Advantage of the flag is that it > integrates nicely with flag that's already there. As I said I'm not against this - I significantly prefer a new API rather than flags for the reasons I stated earlier. pn_messenger_set_allowed_sasl_mechs() seems like a reasonable (if wordy) name (together with an accessor pn_messenger_get_...). > > For the flags I've done the work and can send a PR. I also fixed the > bug I filed yesterday about pn_messenger_set_flags in one go as it's > the same function. Can you point me at the JIRA for this bug? Thanks Andrew
RE: SASL negotiation w/ EXTERNAL
Hi Andrew, I agree that the server should only offer EXTERNAL when the client has presented a valid cert. We have the case that we still want to use PLAIN or ANONYMOUS even in that case, however, since we'll want to use a particular permissions-bound key not representable by the cert, or differentiated per-node (link) access control with the AMQP claims-based model, while also making sure that the connecting client is authorized to make the connection in the first place. The broker gateway handles the cert and we offer EXTERNAL, but the client then opts not to use that identity but rather want to use CBS or a particular permissions-bound key. So I/we would really like to have an override hook for this. The flags seem cheap; apn_messenger_set_allowed_sasl_mechs() function would be just as cheap. Advantage of the flag is that it integrates nicely with flag that's already there. For the flags I've done the work and can send a PR. I also fixed the bug I filed yesterday about pn_messenger_set_flags in one go as it's the same function. Best Regards Clemens -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Mittwoch, 9. September 2015 16:58 To: proton@qpid.apache.org Subject: Re: SASL negotiation w/ EXTERNAL On Wed, 2015-09-09 at 09:27 +, Clemens Vasters wrote: > Hi Qpid Proton, > > tl;dr: I'm working with Proton-C 0.10 and would like to have explicit > override options to keep Proton-C from automatically picking up on > EXTERNAL when being offered by the server - while using the messenger > layer. > > By what I can see, currently Proton-C's messenger automatically picks > up EXTERNAL as the default mechanism whenever offered by the server, > and when a username has been configured for the target URI. I believe > Proton-C s only needs to pick up on EXTERNAL under two explicit > circumstances: I'm going to assume that you are using the default implementation of SASL with Proton (as I'm guessing you are using Windows), however the Cyrus SASL implementation behaviour should be pretty much identical. As you imply, the Proton SASL implementation has a preference for more secure authentication where available over less secure authentication. However it will only choose EXTERNAL iff there was a client certificate that the server authenticated already. So if you are seeing EXTERNAL being chosen over PLAIN then you must have a valid client certificate that the server accepted. Remember it is the server that is responsible for offering mechanisms. If the server didn't accept the SSL client certificate it shouldn't have offered EXTERNAL. The client will always choose EXTERNAL (by default) because it is a more secure option than PLAIN. Using the pn_sasl_allow_mechs() API you can restrict which mechs a client (or server) will consider using. However currently the messenger API has no easy way to use this API - this would be a reasonable area for an API addition - although I'm not sure about simply introducing new flags, there seems to be no end of them once started and it gets hard to figure out the interactions between them pretty soon. However fundamentally It seems to me that no server should offer EXTERNAL as a mechanism unless the client *is already* authenticated via SSL. So if it is offered then they should be no way for the client to select it and it fails. I'm pretty sure that this is the behaviour of the Proton library with Cyrus SASL used as a server. It could be that I am misunderstanding how SSL certificates work in this case, and it is definitely possible there is a bug in the code as it runs on Windows, as I haven't tested client certificate scenarios very much in that environment. Andrew
Re: SASL negotiation w/ EXTERNAL
On Wed, 2015-09-09 at 09:27 +, Clemens Vasters wrote: > Hi Qpid Proton, > > tl;dr: I'm working with Proton-C 0.10 and would like to have explicit > override options to keep Proton-C from automatically picking up on > EXTERNAL when being offered by the server - while using the messenger > layer. > > By what I can see, currently Proton-C's messenger automatically picks > up EXTERNAL as the default mechanism whenever offered by the server, > and when a username has been configured for the target URI. I believe > Proton-C s only needs to pick up on EXTERNAL under two explicit > circumstances: I'm going to assume that you are using the default implementation of SASL with Proton (as I'm guessing you are using Windows), however the Cyrus SASL implementation behaviour should be pretty much identical. As you imply, the Proton SASL implementation has a preference for more secure authentication where available over less secure authentication. However it will only choose EXTERNAL iff there was a client certificate that the server authenticated already. So if you are seeing EXTERNAL being chosen over PLAIN then you must have a valid client certificate that the server accepted. Remember it is the server that is responsible for offering mechanisms. If the server didn't accept the SSL client certificate it shouldn't have offered EXTERNAL. The client will always choose EXTERNAL (by default) because it is a more secure option than PLAIN. Using the pn_sasl_allow_mechs() API you can restrict which mechs a client (or server) will consider using. However currently the messenger API has no easy way to use this API - this would be a reasonable area for an API addition - although I'm not sure about simply introducing new flags, there seems to be no end of them once started and it gets hard to figure out the interactions between them pretty soon. However fundamentally It seems to me that no server should offer EXTERNAL as a mechanism unless the client *is already* authenticated via SSL. So if it is offered then they should be no way for the client to select it and it fails. I'm pretty sure that this is the behaviour of the Proton library with Cyrus SASL used as a server. It could be that I am misunderstanding how SSL certificates work in this case, and it is definitely possible there is a bug in the code as it runs on Windows, as I haven't tested client certificate scenarios very much in that environment. Andrew
