Security

Manage authentication, groups, and platform-wide access control.

How Platform Security Works

Security in Bosca is built around a group-based permission model that governs access to every entity in the platform — content, collections, projects, analytics resources, scripts, configuration, and administrative operations. Every authenticated user belongs to one or more groups, and those group memberships determine what the user can see and do.

The security system operates at the platform level, meaning the same access control rules apply consistently across all subsystems. Whether a user is accessing content through the studio interface, querying analytics data, or invoking a script via API, the platform evaluates their permissions in the same way.

Group Management

Groups are the foundation of access control. Every permission grant in the platform targets a group, not an individual user. This makes it straightforward to manage access at scale — add a user to a group and they immediately inherit all of that group's permissions.

System Groups

The platform ships with several built-in groups that cover common organizational roles:

Custom Groups

Beyond the built-in groups, administrators can create custom groups tailored to their organization's structure. Custom groups work exactly like system groups — they can be granted permissions on any platform entity and assigned to any user. Common uses include:

• Department-specific groups that limit access to a particular content area or project.
• External partner groups with restricted read-only access to specific collections.
• Review groups that can approve content transitions but not edit content directly.
• Integration groups assigned to API tokens for third-party system access.

Authentication Context

When a user or service makes a request to the platform, the security system establishes an authentication context that identifies who is making the request and what permissions they hold. This context is carried through every operation the request triggers, ensuring consistent permission evaluation even when an operation spans multiple internal services.

The authentication context includes:

• User identity. The authenticated user's unique identifier and profile information.
• Group memberships. All groups the user belongs to, including system and custom groups.
• Effective permissions. The combined set of permissions derived from all group memberships.
• Token metadata. For API token-based authentication, the token's scopes and expiration.

API Tokens

API tokens provide long-lived credentials for programmatic access to the platform. They are used by external integrations, CI/CD pipelines, automated scripts, and any system that needs to interact with the platform without a human user present.

• Token creation. Administrators generate tokens through the system administration interface. Each token is associated with a specific user account whose group memberships determine the token's effective permissions.
• Optional scopes. Tokens can be restricted to specific scopes, limiting what operations they can perform even if the associated user has broader permissions. This follows the principle of least privilege.
• Token management. View all active tokens, see when each was last used, and revoke tokens that are no longer needed or may have been compromised.

Encryption at Rest

Sensitive values stored in the platform's configuration system are encrypted at rest using nonce-based encryption. This protects API keys, database credentials, third-party service secrets, and other sensitive settings from being exposed if the configuration data store is accessed directly.

Encryption is transparent to services that read configuration values through the platform API — values are decrypted automatically when accessed by authorized code. The encryption keys themselves are managed separately from the encrypted data.

Script Sandboxing

Scripts running within the platform operate in a sandboxed environment that restricts their access to system resources. The sandbox uses restricted class loading to prevent scripts from:

• Accessing the host filesystem or operating system commands.
• Opening arbitrary network connections.
• Loading classes outside of the approved API surface.
• Accessing platform internals that are not part of the script API.

This sandboxing ensures that even if a script contains a vulnerability or is written by a less-trusted administrator, it cannot compromise the security of the broader platform. Scripts interact with platform services only through the controlled API context provided to them.

Permission Model

The permission model is group-based and applies uniformly across all platform entities. When a permission is granted, it specifies three things: the group receiving the permission, the entity the permission applies to, and the type of access being granted.

Permission types include:

• View. Read access to the entity and its data.
• Edit. Modify the entity's content, metadata, or configuration.
• Manage. Full control including the ability to grant permissions to other groups, delete the entity, or change its workflow state.

Permissions are evaluated by checking whether any of the requesting user's groups have been granted the required permission type on the target entity. If any group match is found, the operation is allowed. This means a user who belongs to multiple groups effectively has the union of all those groups' permissions.

Administrative Routes

All administrative operations — managing groups, creating API tokens, editing configuration, deploying scripts, and monitoring jobs — require membership in the admin group. This is enforced at the API level, so administrative operations cannot be performed even if a non-admin user somehow accesses the administration interface.

The separation between administrative and non-administrative access ensures that day-to-day platform users (content editors, analysts, audience managers) cannot accidentally or intentionally modify system-level settings that affect all users.