This page describes how the Sentinel Authentication Gateway uses a Cassandra database for sharing bootstrapped security association details between the BSF and XCAP servers.

Below are details of the database configuration, performance recommendations, and schema.

Cassandra database configuration

An administrator is required to download and set up a Cassandra Database.

Note Check the Sentinel Authentication Gateway Compatibility Guide for supported versions of Cassandra.
Warning Before installation, read Cassandra’s Getting Started page.

For a test system, a single Cassandra database instance may be sufficient if redundancy is not a requirement.

Minimal production recommendations

For a minimal production system, in order to tolerate a single failure in the Cassandra database there should be at least three nodes configured per site. The Cassandra replication factor should be 3.

Higher replication factors can be used on larger clusters. The recommended consistency level for this storage system is the LOCAL_QUORUM consistency level. All read and write queries are programmed to use LOCAL_QUORUM as the consistency level.

It is assumed that in a multi-site deployment, an appropriate Snitch and topology strategy are used. As a basis, we suggest use of the NetworkTopologyStrategy and GossipingPropertyFileSnitch, then reading the relevant links below to review this selection.

Tip
Cassandra references

Performance recommendations

OpenCloud recommend that Cassandra’s data commit log directories are on different physical devices (different disks). If this is not possible, then different partitions on the same device is acceptable.

(OpenCloud performance testing shows that there are benefits to using different partitions on the same device when there are 1000 or more Cassandra DB transactions per second.)

Data schema

Cassandra’s tables exist in a 'keyspace', which for illustrative purposes can be thought of as a 'database' in SQL implementations.

Creating the keyspaces

Creating a keyspace is simple, but note the following:

  • The keyspaces must be named opencloud_gaa_bootstrap_info and opencloud_nonce_info.

  • For a production environment, the keyspaces can be created such that it is replicated. A sample CQL command for creating such a keyspace is:

    CREATE KEYSPACE opencloud_gaa_bootstrap_info WITH REPLICATION={'class' : 'SimpleStrategy', 'replication_factor' : 3 };

CREATE KEYSPACE opencloud_nonce_info WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 3 };

  • For testing purposes, replication may not be necessary. A sample CQL command for creating such keyspaces is:

    CREATE KEYSPACE opencloud_gaa_bootstrap_info WITH REPLICATION={'class' : 'SimpleStrategy', 'replication_factor' : 1 };

CREATE KEYSPACE opencloud_nonce_info WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 1 };

Creating the tables

Once the keyspaces have been created, the required tables can be created. The following CQL statements provide both the structure and insight into the tables that are required:

USE opencloud_gaa_bootstrap_info;

CREATE TABLE impi_by_tmpi (
    tmpi text,
    impi text,
    PRIMARY KEY (tmpi)
)
WITH gc_grace_seconds = 172800; // 2 days

CREATE TABLE guss_by_impi (
    impi text,
    guss_data blob,
    PRIMARY KEY (impi)
)
WITH gc_grace_seconds = 172800; // 2 days

CREATE TABLE auth_vector (
    id blob,
    impi text,
    tmpi text,
    realm text,
    rand blob,
    autn blob,
    xres blob,
    ck blob,
    ik blob,
    ha1 blob,
    key_lifetime int,
    used boolean,
    PRIMARY KEY (id)
)
WITH gc_grace_seconds = 172800; // 2 days

CREATE TABLE bootstrap_info (
    btid text,
    impi text,
    ck blob,
    ik blob,
    rand blob,
    PRIMARY KEY (btid)
)
WITH gc_grace_seconds = 172800; // 2 days

USE opencloud_nonce_info;

CREATE TABLE nonce_storage (
    nonce text,
    timestamp double,
    remoteAddr text,
    seen text,
    PRIMARY KEY(nonce)
)
WITH gc_grace_seconds = 172800; // 2 days
Previous page Next page