A newer version of this documentation is available.

View Latest

Authentication

RBAC requires that users pass appropriate credentials to Couchbase Server in order to access cluster-resources. The SDK provides enhanced support for the passing of credentials.

RBAC and the SDK

Couchbase Server 5.0 Enterprise Edition introduces Role-Based Access Control. This ensures that cluster-resources can only be accessed by users with appropriate privileges. Privileges are grouped in Couchbase-defined sets; and each set is associated with a specific role. Users can each be assigned one or more roles, and are thereby granted the privileges associated with each role.

In order to access cluster-resources, programs, including those supported by the Couchbase SDK, must authenticate with Couchbase Server, and so be identified as existing users, each associated with one or more roles. Authentication requires the passing of credentials; which consist of a username and (in most cases) a password. Users may be defined either locally to Couchbase Server, or externally (for example, by means of an LDAP server).

Once authentication has succeeded, an authorization process checks the roles associated with the identified user. If role-associated privileges correspond to the level of resource-access requested by the user, access is duly granted; otherwise, it is denied.

Authenticating with Legacy SDK Versions

For versions of Couchbase Server 5.0 and beyond, Role-Based Access Control (RBAC) is applied to all cluster-resources. Under RBAC, bucket-passwords are no longer used: instead, a username and user-password must be specified.

All pre-RBAC versions of the SDK can continue to be used with Couchbase Server 5.0 and beyond: the pre-RBAC authentication procedure need not change. However, when passed:

  • The value formerly interpreted as a bucket-name is now interpreted as a username. The username must correspond to a user defined on the cluster that is being accessed.

  • The value formerly interpreted as a bucket-password is now interpreted as the password of the defined user.

Note that on Couchbase Server 5.0 and beyond, the only buckets that can be accessed without a user-password are those that were created on legacy versions of the server; were not originally created with a bucket-password; and continue to be available on 5.0 and beyond, following the required upgrade process. See Upgrading to RBAC for information on server-upgrade to 5.0, and how this affects access to legacy buckets.

On Couchbase Server 5.0 and beyond, for any bucket to be accessed successfully, the defined user attempting access must have been assigned appropriate roles. See Manage Users and Roles for information on user-management.

Passing Credentials

The most recent versions of the SDK are RBAC-enabled, and provide enhanced support for authentication. Code examples for .NET can be found in Getting Started with the SDK, and also as part of the Sample Code provided to demonstrate user management.

Upgrading to RBAC-Enabled SDK-Versions

The last pre-RBAC version of the .NET SDK was 2.4.2. The first RBAC-enabled version was 2.4.4. See the SDK Release Notes for more information.

With the most recent versions of the SDK, the legacy authentication interface and the new, optimized authentication interface can both be used: each supports access to buckets on Couchbase Servers whose version is either 5.0 and beyond, or pre-5.0.

Further Information on RBAC

All aspects of the Couchbase RBAC system are covered in the section Authorization. Specifically, for information on:

Certificate-Based Authentication

Couchbase Server supports the use of X.509 certificates to authenticate clients (only available in the Enterprise Edition, not the Community Edition). This allows authenticated users to access specific resources by means of the data service, in Couchbase Server 5.1 and up, and all other services in more recent releases of Couchbase Data Platform.

The process relies on a certificate authority, for the issuing of certificates that validate identities. A certificate includes information such as the name of the entity it identifies, an expiration date, the name of the authority that issued the certificate, and the digital signature of the authority. A client attempting to access Couchbase Server can present a certificate to the server, allowing the server to check the validity of the certificate. If the certificate is valid, the user under whose identity the client is running, and the roles assigned that user, are verified. If the assigned roles are appropriate for the level of access requested to the specified resource, access is granted.

Note that this means that the explicit authentication process otherwise required by Couchbase Role-Based Access Control — whereby, in .NET, username and password are passed by means of the authenticate method on the Cluster object — is not needed. (See Start Using the SDK for an example of such standard authentication.)

For a more detailed conceptual description of using certificates, see Certificates.

For sample procedures whereby certificates can be generated and deployed, see Manage Certificates. Note that this section includes the steps whereby a Java keystore is created, to enable certificate-based authentication by a Java client; for Windows there are a couple of more steps: you’ll need to generate a Personal Information Exchange (.PFX) file and store that in the Windows cert store.

Authenticating a .NET Client by Certificate

To authenticate with Couchbase Server by means of a client certificate, you will need a key - which can be generated according to the X.509 certificate requirements.

Once you have generated the .pem file, for windows you’ll need to use it to create a .pfx:

openssl pkcs12 -export -in cert.cer -inkey key.pem -out certificate.pfx -certfile CA.cer

The .pfx is then stored in the Windows certificate store of the application server by copying it to that server and then right clicking on the file and selecting "Install Certificate" and following the steps (there are a couple of ways to do this, but this is the simplest).

Once the .pfx is installed, the client configuration will have to be changed to use cert as opposed to the usual Username and Password:

var config = new ClientConfiguration
{
    UseSsl = true
};

var cluster = new Cluster(config);
var authenticator = new CertAuthenticator(
    new PathAndPasswordOptions
    {
        Path = "C:\path\to\client.pfx",
        Password = "password"
    }
);
cluster.Authenticate(authenticator);

var bucket = cluster.OpenBucket();

Using a Different Certificate Factory

Note that there is also a way to query the cert store directly by using a different certificate factory:

var config = new ClientConfiguration
{
    UseSsl = true
};

var cluster = new Cluster(config);
var authenticator = new CertAuthenticator(
    new CertificateStoreOptions
    {
        StoreLocation = StoreLocation.LocalMachine,
        StoreName = StoreName.Root,
        X509FindType = X509FindType.FindByIssuerName,
        FindValue = "MyCompanyIntermediateCA"
    }
);
cluster.Authenticate(authenticator);

var bucket = cluster.OpenBucket();