114ba8f7 featured anyx admin conceptspolicies and permissions

Policies and permissions

CONTACT

The heart of Agilicus AnyX is precise authorisation: deciding, for each user and each resource, exactly what that user may do. The portal gives you four related mechanisms: permissions, policies, resource groups, and labels.

Users, groups, and service accounts

Access is granted to identities:

  • Users are people. Each user signs in through an identity provider.
  • Groups collect users so you can grant access in bulk and mirror the group structure from your identity provider.
  • Service accounts are non-human identities used by software and automation.

See Users, Groups, and Service accounts.

Permissions

A permission is a specific right on a specific resource or application:

  • for an application, permissions can be roles within the application (for example read-only, operator, administrator);
  • for a resource such as a share or a desktop, permissions are access levels such as read/write or read-only.

Permissions are granted per user or per group, and can be for a single resource or for a resource group. The portal separates:

%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
flowchart LR
    U[User] --> G[Group]
    U --> SA[Service account]
    G --> P[Permission]
    SA --> P
    P --> APP[Application role]
    P --> RES[Resource access level]
    RG[Resource group] --> RES
    LAB[Label] --> P

Policies

A policy is a set of rules that control access beyond the basic permission grant. Common policy rules include:

  • geolocation rules: allow or deny access based on the user’s location (for example deny access from specific countries);
  • firewall rules: allow or deny specific sources, paths, or conditions; and
  • request rules: require approval before access is granted.

Policies can apply to users or groups and can be linked to resources or labels. When a user requests a resource, the policy is evaluated together with the permission grant. See Policies.

Resource groups

A resource group is a named collection of resources. Instead of granting permissions one resource at a time, you grant permissions to the whole group. This is essential when you have many resources (for example a fleet of desktops or a set of applications) that should be managed together. See Resource groups.

Labels

A label is a tag you can attach to any object. Labels let you organise resources and users, and can be used by policies and permissions to grant or restrict access by tag. See Labels.

The request flow

An administrator can enable a request flow so that users who do not yet have access can request it. The request appears in the portal for an administrator to approve or deny. Once approved, the user’s access is granted. See Resource requests.

%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
sequenceDiagram
    participant U as User
    participant P as Portal
    participant A as Administrator
    U->>P: Requests access to a resource
    P-->>A: Request notification
    A-->>P: Approves or denies
    P-->>U: Access granted or denied (recorded in audit)

Combining the mechanisms

A typical configuration combines all of them:

  • a group of users with a shared role;
  • a resource group containing the resources they need;
  • a permission granting the group the appropriate level on the resource group;
  • a label such as internal-only on the resources;
  • a policy denying access from restricted locations; and
  • the request flow enabled so new users can ask for access.

See also

Web guide