Regulation & User Management

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;
}

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 (ex. "// auth: PII, HIPAA"), the database will reject any request unless the User's Authorization has both the PII and HIPAA authorizations. See Schema Change for an example schema.

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)
}

OLAP, OLTP, and Graph APIs will allow users with read privileges but no authorization to create workloads that use the schemas as inputs. However, extraction of the protected schemas data contents will be blocked unless authorized. This enables operating on sensitive data without needing to expose the data.

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

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() };

Note: All C# and Java examples are untested and generated with Gemini based on other language examples. Validation planned for Q3 based on bandwidth. Validated contributions welcome at support@roguedb.com.