You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most deployments of memcached today exist within trusted networks where clients may freely connect to any server and the servers don't discriminate against them. There are cases, however, where memcached is deployed in untrusted networks or where administrators would like to exercise a bit more control over the clients that are connecting. This page mostly exists to describe the protocol.
Authentication Concepts
Authentication is abstracted from the server using the Simple Authentication and Security Layer. Among other things, this provides administrators with consistent credential management that is mostly independent from the services that are authenticating clients.
Protocol Definitions
Error Codes and Conditions
There are two status codes provided by the SASL protocol to enable authentication:
Unauthorized
If a message is returned with a status code of 0x20, this is considered an authentication or authorization failure. This may be in response to an explicit authentication command indicating the credentials were not accepted or the authorization was otherwise not granted to access the server.
Continue Authentication
Some SASL mechanisms require multiple messages to be sent between the client and server. If a server responds to an authentication message with a status code of 0x21, this will indicate your client needs to do more work to complete the authentication negotiation.
Authentication Not Supported
If a server responds to an authentication request indicating the command is unknown (status 0x81), it likely doesn't support authentication. It is generally acceptable for the client to consider authentication successful when communicating to a server that doesn't support authentication.
Authentication Requests
List Mechanisms
In order to negotiate authentication, a client may need to ask the server what authentication mechanisms it supports. A command 0x20 with no extras, key, or value will request a mechanism list from the server. The mechanisms are returned as a space-separated value.
Authentication Request
To begin an authentication request, send a request with command 0x21, the requested mechanism as the key, and the initial authentication data as the value if any is required for the chosen mechanism.
Authentication Continuation
If the authentication request responded with a continuation request (status 0x21), the body will contain the data needed for computing the next value in the authentication negotiation. The next step's data will be transmitted similarly to the initial step, but using command 0x22. Note that this includes the mechanism within the key as in the initial request.
Error Reference
+-------------+------------------------------------------+
| Status Code | Meaning |
+-------------+------------------------------------------+
| 0x20 | Authentication required / Not Successful |
| 0x21 | Further authentication steps required. |
+-------------+------------------------------------------+
In order to use memcached in a hostile network (e.g. a cloudy ISP where the infrastructure is shared and you can't control it), you're going to want some kind of way to keep people from messing with your cache servers.
SASL (as described in RFC2222) is a standard for adding authentication mechanisms to protocols in a way that is protocol independent.
Getting Started
In order to deploy memcached with SASL, you'll need two things:
A memcached server with SASL support (version 1.4.3 or greater built with --enable-sasl)
A client that supports SASL
Configuring SASL
For the most part, you just do the normal SASL admin stuff.
# Create a user for memcached.
saslpasswd2 -a memcached -c cacheuser
Running Memcached
In order to enable SASL support in the server you must use the -S flag.
The -S flag does a few things things:
Enable all of the SASL commands.
Require binary protocol only.
Require authentication to have been successful before commands may be issued on a connection.
Overview
Most deployments of memcached today exist within trusted networks where clients may freely connect to any server and the servers don't discriminate against them. There are cases, however, where memcached is deployed in untrusted networks or where administrators would like to exercise a bit more control over the clients that are connecting. This page mostly exists to describe the protocol.
Authentication Concepts
Authentication is abstracted from the server using the Simple Authentication and Security Layer. Among other things, this provides administrators with consistent credential management that is mostly independent from the services that are authenticating clients.
Protocol Definitions
Error Codes and Conditions
There are two status codes provided by the SASL protocol to enable authentication:
Unauthorized
If a message is returned with a status code of
0x20
, this is considered an authentication or authorization failure. This may be in response to an explicit authentication command indicating the credentials were not accepted or the authorization was otherwise not granted to access the server.Continue Authentication
Some SASL mechanisms require multiple messages to be sent between the client and server. If a server responds to an authentication message with a status code of
0x21
, this will indicate your client needs to do more work to complete the authentication negotiation.Authentication Not Supported
If a server responds to an authentication request indicating the command is unknown (status
0x81
), it likely doesn't support authentication. It is generally acceptable for the client to consider authentication successful when communicating to a server that doesn't support authentication.Authentication Requests
List Mechanisms
In order to negotiate authentication, a client may need to ask the server what authentication mechanisms it supports. A command
0x20
with no extras, key, or value will request a mechanism list from the server. The mechanisms are returned as a space-separated value.Authentication Request
To begin an authentication request, send a request with command
0x21
, the requested mechanism as the key, and the initial authentication data as the value if any is required for the chosen mechanism.Authentication Continuation
If the authentication request responded with a continuation request (status
0x21
), the body will contain the data needed for computing the next value in the authentication negotiation. The next step's data will be transmitted similarly to the initial step, but using command0x22
. Note that this includes the mechanism within the key as in the initial request.Error Reference
Command Reference
SASL Howto
Introduction
In order to use memcached in a hostile network (e.g. a cloudy ISP where the infrastructure is shared and you can't control it), you're going to want some kind of way to keep people from messing with your cache servers.
SASL (as described in RFC2222) is a standard for adding authentication mechanisms to protocols in a way that is protocol independent.
Getting Started
In order to deploy memcached with SASL, you'll need two things:
Configuring SASL
For the most part, you just do the normal SASL admin stuff.
Running Memcached
In order to enable SASL support in the server you must use the -S flag.
The
-S
flag does a few things things:P.S.
Original: https://code.google.com/p/memcached/wiki/SASLAuthProtocol
Original: https://code.google.com/p/memcached/wiki/SASLHowto
Motive to duplicate - google source code (with project wikis) is closing.
Plan
The text was updated successfully, but these errors were encountered: