...

Specifically I'd like to somewhat simplify using authentication and encryption with the transport by unifying the most commonly used concepts into the transport code and only requiring delving directly into the SSL/SASL APIs for more complex uses.

API Changes

From the authentication point of view the API flow is radically simpler:

Instead of the current situation where the application has to directly read and write AMQP SASL frames using pn_sasl_recv(), pn_sasl_send() etc. the meat of the protocol interchange happens behind the scenes and instead the application has to set up authentication parameters and then allow the protocol handling loop to handle SASL without application intervention.

At the client the parameters that can be set up include username/password (with pn_transport_set_user_password() ), if necessary the SASL mechanisms used can be affected to either force SASL to use the ANONYMOUS mechanism (pn_sasl_force_anonymous() ) or to exclude some mechanisms offered by the server (pn_sasl_exclude_mechs() ).

By default the server will adapt to whatever layers the client attempts to use to communicate. But the application can specify that the connection must be encrypted or authenticated (using pn_transport_require_encryption() and pn_transport_require_auth() ). Also if required the server application can force the SASL layer to use the ANONYMOUS mechanism or to exclude some mechanisms that might be installed on the system (by using pn_sasl_force_anonymous() or pn_sasl_exclude_mechs() ). The location and name of the configuration file used by the SASL implementation can be changed by using the pn_sasl_config_name() and pn_sasl_config_path() APIs.

SASL

The biggest functional changes happen in the SASL layer code where the API has largely changed, very little backwards compatibility has been kept, because it is fairly clear that very few (if any) people have been using the current API to implement their own SASL mechanisms. If this turns out to be untrue, then we could add some further measure of backwards compatibility as required.

...

• void pn_sasl_client(pn_sasl_t *sasl)

• void pn_sasl_server(pn_sasl_t *sasl)

These functions were used to specify the SASL layer as either a client or server, they have been deprecated since functionality went into the transport code to specify whether it is an authentication client or server. Currently, on creation,  the SASL layer will determine from the transport whether it should be a server or a client. As there is a good deal of SASL churn in these current changes this is a good opportunity to remove these deprecated APIs.

• pn_sasl_state_t pn_sasl_state(pn_sasl_t *sasl)

• size_t pn_sasl_pending(pn_sasl_t *sasl)

• ssize_t pn_sasl_recv(pn_sasl_t *sasl, char *bytes, size_t size)

• ssize_t pn_sasl_send(pn_sasl_t *sasl, const char *bytes, size_t size)

These functions are the ones which support the client directly

• void pn_sasl_mechanisms(pn_sasl_t *sasl, const char *mechanisms)

• const char *pn_sasl_remote_mechanisms(pn_sasl_t *sasl)

...