Avro SASL Profile: For Authentication and Security

Today, in this article, “Avro SASL Profile: For authentication and security” we are discussing Avro SASL profile for connection-based Avro RPC.

Moreover, we will see negotiation and Anonymous Mechanism in SASL Profile in Avro. Along with this, we will discuss Process and Data Session in Avro SASL Profile.

Basically, for authentication and security of network protocols, SASL (RFC 2222) offers a framework. However, each protocol which uses SASL must define a SASL profile. 

So, let’s begin with Apache Avro SASL Profile brief introduction.

What is the Avro SASL Profile?

By using a selected SASL mechanism, SASL negotiation proceeds as a series of message interactions over a connection between a client and server. Moreover, by sending the client’s chosen mechanism name with an initial (possibly empty) message, the client starts this negotiation.

Basically, with the exchange of messages until either side indicates success or failure, Negotiation proceeds. Although the content of the messages is mechanism-specific. Although the session can proceed over the connection only if the negotiation succeeds, else it must abandon.

In addition, even after negotiation, some of the mechanisms continue to process session data but some of the mechanisms does specify that further session data is transmitted unmodified.

Negotiation in Avro SASL Profile

Below, we are discussing Negotiation in Apache Avro SASL Profile:

a. Commands

There are four one-byte commands, which Avro SASL negotiation uses:

i. 0: START

We use it in a client’s initial message.

ii. 1: CONTINUE

At the time when negotiation is ongoing, we use it.

iii. 2: FAIL

This command terminates negotiation unsuccessfully.

iv. 3: COMPLETE

Whereas, this command terminates negotiation successfully.
Format: START message

| 0 | 4-byte mechanism name length | mechanism name | 4-byte payload length | payload data |

Format: CONTINUE message

| 1 | 4-byte payload length | payload data |

Format: FAIL message

| 2 | 4-byte message length | UTF-8 message |

Format:  COMPLETE message

| 3 | 4-byte payload length | payload data |

b. Process

At very first client sends a START command containing the client’s chosen mechanism name and any mechanism-specific payload data, in this way the Negotiation initiates.

Afterward, the server and the client exchange some number (possibly zero) of CONTINUE messages. Basically, to generate the next message, each message consists of a payload data which get processed by the security mechanism. There are two cases possible:

• If the client or server sends a FAIL message, then as a result, negotiation fails. In the failure message, the UTF-8-encoded text is present. So, communication on this connection gets cease, if a FAIL message has been sent or received, or any other error occurs in the negotiation.
• Or if the client or the server sends a COMPLETE message, then as a result negotiation completes successfully. So, as a result, until the connection gets close by either side, Session data may now be transmitted over the connection.

Session Data in Avro SASL Profile

All subsequent writes to/reads over the connection are written/read unmodified if no SASL QOP (quality of protection) is negotiated. Specifically, messages are of the following form and also uses Avro framing:

| 4-byte frame length | frame data | … | 4 zero bytes |

Further, for all subsequent messages, the connection must use a SASL QOP if it is negotiated. It is possible by only one way, that is by using the security mechanism, wrapping of each non-empty frame written and also by unwrapping of each non-empty frame read.

Basically, in each non-empty frame, the length written is the length of the wrapped data. Though, for unwrapping, complete frames must be passed to the security mechanism. Further, all the Unwrapped data is passed to the application as the content of the frame.

However, all further communication on this connection must cease, if at any point processing fails due to wrapping, unwrapping or framing errors.

Anonymous Mechanism

However, it is very simple to implement SASL anonymous mechanism (RFC 2245). Though, by the following static sequence, an initial anonymous request may be prefixed, in particular:

| 0 | 0009 | ANONYMOUS | 0000 |

A server should check that the mechanism name in the start message, prefixing the first request received is ‘ANONYMOUS’, if a server uses the anonymous mechanism, then simply prefix its initial response with a COMPLETE message of:

| 3 | 0000 |

An anonymous server may respond with a FAIL message if an anonymous server receives some other mechanism name, as simple as:

| 2 | 0000 |

Make sure that the anonymous mechanism need add no additional round-trip messages between client and server. However, on the initial request or response, the START message and the COMPLETE or FAIL message can be piggybacked.

So, this was all in Avro SASL Profile. Hope you like our explanation.

Conclusion: Avro SASL Profile

Hence, we have learned all about Apache Avro SASL Profile for authentication and security purpose. Hope it helps!