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 keyspace

Creating a keyspace is simple, but note the following:

  • The keyspace must be named keyspace-name.

  • For a production environment, the keyspace 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 };

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

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

Creating the tables

Once a keyspace has 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)
);

CREATE TABLE guss_by_impi (
    impi text,
    guss_data blob,
    PRIMARY KEY (impi)
);

CREATE TABLE auth_vector (
    id blob,
    impi text,
    tmpi text,
    realm text,
    rand blob,
    autn blob,
    xres blob,
    ck blob,
    ik blob,
    key_lifetime int,
    used boolean,
    PRIMARY KEY (id)
);

CREATE TABLE bootstrap_info (
    btid text,
    impi text,
    ck blob,
    ik blob,
    rand blob,
    PRIMARY KEY (btid)
);
Previous page Next page