Role and Policy Architecture

SANKET separates five things that are often merged: who a person is, what they are allowed to do, which content they can cryptographically read, which devices are trusted, and what administrative power they hold.

Table 28: Five distinct control concepts

The separation matters because authorisation and cryptographic access can diverge in useful ways. Removing a member from a group is an authorisation change that immediately removes their devices from future fan-outs; no administrator can, by changing a role, give a device the ability to decrypt messages that were never encrypted to it.

15.1 Administrator Roles (RBAC)

Administrator permissions are organised into categories (users, broadcast, vault, audit log, settings, alerts, licence, integrations and location), each with read, create, edit and delete actions. Five built-in roles are provided and cannot be altered; customers can define additional roles, but an administrator cannot create or assign a role with more permission than they hold. Every administrator, whatever the role, is subject to the same strong-authentication policy (Chapter 13). When administrators sign in through the customer's identity provider, roles still come from the console unless the owner enables a group-to-role map, and that map can never grant the Owner role.

Table 29: Built-in administrator roles

Customers map these to their own structure, for example Organisation Administrator (Owner), Security Administrator (Threat Monitor plus a custom role with user-edit permission for lost-device handling), and Auditor.

15.2 Group Roles

Table 30: Group roles and permissions

Member approval is on by default: an added member is pending until they accept, so nobody is placed into a conversation without consent. Group creation is itself a policy; a deployment chooses the model that suits its structure. Under the administrators-only policy, the default, administrators with the user-creation permission create groups from the console, naming an active end user as the owner and the initial members by Sanket ID; member approval applies to them as to any group, and each creation is audited. Notice broadcasts, the announcement type that is labelled as not end-to-end encrypted, can be sent only by administrators with the broadcast-creation permission, and only the administrator who created a notice can edit or send it.

15.3 Broadcast-Sender Accounts

Administrators hold no libsignal identity, so they cannot send end-to-end encrypted content. Encrypted broadcasts are therefore sent by a dedicated broadcast-sender account: a user account with its own Sanket ID, created, suspended and assigned to named administrators in the console, with every such action audited. It is excluded from contact search, from "all users" audiences and from ordinary chats. Its root of trust is a mobile device in the organisation's custody, and its sending desktop must be approved both by that mobile and in the administrator console. The desktop app encrypts each broadcast for every recipient device through its own libsignal Double Ratchet session, with no sender keys; recipients pin the sending device and identity on the first broadcast and are warned if a later broadcast comes from another device or key. Sending is a desktop function by design; receiving is identical on mobile and desktop. Chapter 17 describes the broadcast lifecycle.

15.4 End-User Policy Controls

Policies apply to the whole installation and are set by administrators with the settings permission. Clients receive a reduced copy of the policy from which sensitive values, such as lockout thresholds and rate limits, are removed. The principal enforced controls are:

Table 31: Enforced policy controls (selection)

15.5 Attribute-Based and Hierarchical Policy

SANKET's current model is role-based for administrators and membership-based for content, with installation-wide policy. It does not implement attribute-based access control, per-department policy or an organisational hierarchy with inherited permissions. Large organisations typically deploy separate installations for separate security domains, which gives strong compartmentalisation at the cost of cross-domain communication, and installation-level separation remains the recommended separation between formally accredited levels. Per-message and per-file classification labels are implemented (Chapter 38); hierarchical units, attribute-based policy, conversation-level labels and a per-label handling matrix are roadmap directions.