Skip to main content
Use the In-Game Permissions area in Portal to manage authorization for a Minecraft network. Portal access authorizes administration only; it never becomes a Minecraft role or a player runtime permission.
Project owners and editors can manage their project’s permissions. Project viewers have read-only access. Production permission administration requires separate platform access.

​
Roles

Create a role with a name, optional display metadata, and optional default status. Default roles apply to every player. Build reusable roles with inheritance, for example moderator inheriting member; Portal rejects cycles.

​
Role grants

Use exact nodes when possible. The most specific matching scope wins; a deny wins between equally specific candidates.

​
Players

Search a player to review assigned roles, direct grants, and effective access. Use a direct role grant for a reusable exception and a direct permission grant for one narrow exception. Both can expire. Verify the selected environment, server type, and server in effective access before testing in-game.

​
Assignment sources

The effective access view combines all of these sources for a player: Group mappings and direct role assignments are role assignments, not direct permission-node grants. A mapped or directly assigned role contributes its own grants and any inherited roles. The effective access view identifies whether a role or grant came from a default role, group mapping, direct role assignment, direct permission grant, or role inheritance.
Removing a grant does not kick a connected player. The change applies when the runtime refreshes a snapshot and makes a later check.

​
Keycloak group mappings

Map a Keycloak group to a Minecraft role for normal long-lived access. Portal reads groups but does not create, rename, or delete them; manage membership in Keycloak. An optional mapping expiry supports temporary group-derived access. The mapped role supplies the permissions; groups do not receive direct permission-node grants.

​
Sync production policy into a project

Use Sync from global to compare the current production policy with a project before changing project data. The preview includes roles, role grants, role inheritance, and catalog entries.
The sync never transfers direct player-to-role assignments or direct player permission grants. Review and manage player-specific access inside the target project.
1

Preview production changes

Open Sync from global. Portal compares the latest production snapshot with the project’s current permission state without changing the project.
2

Choose how to resolve conflicts

For each conflict, choose Keep project, Use global, Skip, or Remove project when that action is available. Review additions and removals before continuing.
3

Choose whether to include Keycloak mappings

Enable Include Keycloak mappings only when production group-to-role mappings should replace or extend the project mappings. When disabled, existing project mappings remain local to the project.
4

Apply the preview

Confirm the import. If the project changed after the preview was created, Portal rejects the stale preview without changing project data. Create a new preview and review it again.

​
Permission catalog

The catalog lists workload-registered nodes and administrator-created custom entries. Catalog metadata does not grant access by itself. See Register permission nodes before creating a workload-owned entry.

​
Audit

Open Audit in In-Game Permissions to review Minecraft authorization changes. Filter by action family and UTC time range, search by actor, action, or target, and page through the newest events first. Each event records an actor (a Portal administrator or system actor), action, technical target, time, and a non-sensitive change summary. Historical events without an actor display as Unknown. This history is separate from the Portal Access audit.
1

Create the least-privileged role

Create the smallest role that supports the player action. Add a scoped deny only when an inherited or wildcard allow must be excluded.
2

Map normal membership

Map the appropriate Keycloak group to the role. Prefer this over direct player grants for a team whose membership is maintained in Keycloak.
3

Add temporary exceptions

Use an expiring player role or direct player grant for a short-lived exception. Confirm its expiry before saving it.
4

Verify effective access

Open the player’s effective access view for the target server type or server. Confirm the resulting roles and patterns for the target environment, server type, and server before testing in-game.