This page is a technical overview of how Gatekeeper sits in the Unique platform: what it is, how other services call it, and how identity from Zitadel becomes an allow or deny decision.

For the admin UI, system roles, and operating modes, start with the parent page: Access Management for Admins.

How Gatekeeper fits the platform

Gatekeeper is a dedicated authorization service. Other Unique backends do not decide access on their own. They ask Gatekeeper whether a user may perform an action on a resource in a company.

Three flows:

1. Enforcement (authoritative). When a user performs an action, the backend service asks Gatekeeper: is this allowed? Gatekeeper evaluates the request against stored policies and returns allow or deny.

2. UI permissions (hints only). Chat and Admin ask what the user should see (menus, buttons, pages). Those flags are convenience only. Every sensitive server operation still goes through the enforcement path above.

3. Identity sync. Role and group changes in Zitadel are forwarded through Unique backend services into Gatekeeper, so policies stay aligned with the identity provider.

What Gatekeeper does

Gatekeeper centralizes authorization for Unique. Domain services call it over GraphQL; they do not embed the policy engine themselves.

• Enforcement. Evaluates whether a user or group may perform an action on a resource in a company context. Decisions use an in-memory Casbin enforcer. Policies are persisted in PostgreSQL.

• Policy model. Allow/deny rules, user-to-role assignments in a company, and group relationships. System role templates define which resources and actions each platform role grants.

• Identity sync. Zitadel roles are mapped to Gatekeeper roles and written as grouping policies, typically after Zitadel webhooks are handled by Scope Management.

• API. GraphQL exposes permission checks, role and permission queries, and policy administration. Other backends call it with service identity.

Server-side enforcement is the authority

UI checks ("can this user see this button?") are not the security boundary. Every sensitive server operation is authorized by Gatekeeper on the domain API. Hiding a control in the UI does not grant or deny access.

Policy provisioning

Zitadel role changes and built-in role templates both end up as Casbin policies in Gatekeeper's Postgres store.

Authorization request flow

At runtime, every sensitive backend operation asks Gatekeeper to evaluate the request. Casbin returns allow or deny, and the backend service applies that decision according to its operating mode.

Backend authorization request flow

Domain services call Gatekeeper through a shared client. Gatekeeper evaluates the request in Casbin against policies stored in PostgreSQL.

Admin UI request flow

The Access Management UI talks to Gatekeeper's GraphQL API directly for role, group, and policy administration.