Regulation & User Management

RogueDB enforces security and compliance at the database level, per schema, for every request. Instead of writing manual authorization logic in your application, you define access rules within the User schema.

1. The User Identity Model

Every actor interacting with RogueDB — whether a microservice, an admin, or an end-user—must have a record in the system-provided User schema.

message User
{
    string api_key = 1; // index-1
    string name = 2;
    map<string, Permission> permissions = 3;
    Authorization authorization = 4;
    bool admin = 5;
    bool monitor = 6;
}

2. Enum Authorization Logic

RogueDB uses enums designed for bitmask operations for both permissions and authorizations. This provides flexibility for either directly specifying the enum or aggregating with bitmask or logic.

Table-Level Permissions (Permission)

Permissions follow a POSIX-style bitmask. You assign these per schema name in the permissions map (e.g., "Orders": READ_WRITE).

Regulatory Enforcement (Authorization)

While permissions control actions, authorization controls data regulation compliance. If a schema is tagged with a directive like // auth: PII, HIPAA, the database will reject any request unless the User's Authorization has both the PII and HIPAA authorizations.

enum Authorization {
    NO_AUTHORIZATION = 0;
    CRITICAL = 1;
    SENSITIVE = 2;
    INTERNAL = 4;
    FINANCIAL = 8;
    GDPR = 16;
    HIPAA = 32;
    PII = 64;
    PUBLIC = 128;
    LEGAL = 256;
    CPRA = 512;
    PCIDSS = 1024;
    SOC2 = 2048;
    // ... combine via bitwise OR (e.g., PII | HIPAA = 96)
}

3. The Enforcement Flow

When a request arrives, the database performs a three-step validation check in microseconds:

4. Provisioning a Scoped User

To create a new user, use your Master API Key to perform an Insert into the User schema.

// Note: Use CRUD API to manage users.
rogue::services::Insert request{};
request.set_api_key(API_KEY);
rogue::services::Registry& registry{ *request.add_messages() };
rogue::services::User& user{ *registry.mutable_user() };

user.set_api_key("UUIDv4");
user.set_name("internal_name");
(*user.mutable_permissions())["Test"] = rogue::services::Permission::READ_WRITE;
(*user.mutable_permissions())["User"] = rogue::services::Permission::READ;
user.set_authorization(rogue::services::Authorization::PII_FINANCIAL_INTERNAL_SENSITIVE_CRITICAL);
user.set_admin(false);
user.set_monitor(false);

std::unique_ptr<rogue::services::RogueDB::Stub> roguedb{ rogue::services::RogueDB::NewStub(
    grpc::CreateChannel(
        std::format("{}:443", URL),
        grpc::SslCredentials(grpc::SslCredentialsOptions()))) };
        
grpc::ClientContext context{};
context.AddMetadata("Authorization", std::format("Bearer {}", ENCODED_JWT));
auto stream{ roguedb->insert(&context) };
// auto stream{ roguedb->update(&context) }; // Update API
// auto stream{ roguedb->remove(&context) }; // Remove API

stream->Write(request);
stream->WritesDone(); // Signal all queries sent. Otherwise, blocks.
    
// No response is given for Insert, Update, and Remove
// Any errors get reported in status.
grpc::Status status{ stream->Finish() };

5. Implementation Benefits