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.

​
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 server type or 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.

​
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 before testing in-game.