Authorization Model

Once Thinfinity® Workspace verifies who a user is, the authorization model determines what they can see and do. This section explains the three levels at which that authorization operates, how those levels relate to each other, and where each one is configured.

The Authorization Model

Authorization in Thinfinity Workspace is not a single permission flag — it is a layered model with three distinct levels, each with its own scope:

Each level builds on the previous one. A user must first have the platform-level visibility to reach a feature, then the profile-level access to connect to a resource, and optionally the label-based rules that govern visibility across groups of profiles.

Level 1 — User Interface Permissions

User Interface Permissions control which modules and features of Thinfinity Workspace a user or group can see and use. These permissions apply across the entire platform, independently of which specific resources that user may later be allowed to connect to.

The configurable modules include:

• Analytics — access to usage and session analytics dashboards
• Web Manager — access to the browser-based administration interface
• Cloud Manager — access to cloud resource management
• Audit Logs — access to the platform’s audit trail
• Config Manager — access to the desktop Configuration Manager application
• Monitoring — access to active session monitoring

Permissions are assigned per user or per directory group. A user who belongs to a group that has been granted access to Analytics, for example, can access the Analytics module regardless of which Access Profiles are assigned to them.

Level 2 — Access Profile Permissions

An Access Profile defines a remote resource that users can connect to — a published desktop, a remote application, a terminal session, or similar. Access Profile permissions control who can connect to each profile and under what role.

Inherited vs. Explicit Permissions

Each Access Profile has an Inherit label access permissions option:

• When enabled (the default), the profile follows the permission rules of any Label it belongs to. Access is determined by who has been granted access to the containing Label.
• When disabled, the profile’s own permission list takes precedence over Label rules. This is used when a profile inside a Label should be accessible to a narrower or different set of users than the rest of the Label.

Roles and Permission Groups

When working with the Resource Reservation feature, each Access Profile does not simply grant or deny access with a binary flag. Instead, access is defined through roles, which are created and managed using Permission Groups.

A default role named Access is created automatically for every profile. It grants immediate connection rights to the profile. Beyond this default, administrators can define custom roles using the built-in permission set. These permissions map to the platform’s Resource Reservation add-on and include roles such as:

• Direct Access — the user can connect without further approval
• Requires Authorization — the user can request access, but must be approved
• Can Authorize — the user can approve access requests from others
• Can Self-Book — the user can reserve a session slot independently

A user or group can be assigned a specific role for a given profile.

Roles are per-profile: the same user can hold different roles across different Access Profiles.

Anonymous Access

An Access Profile can be published without requiring authentication. When Allow Anonymous Access Profiles is enabled for the installation (the default), each profile’s Permissions tab gains an Allow anonymous access option; turning it on makes that profile reachable by anyone who opens Thinfinity Workspace. If anonymous Access Profiles are disabled installation-wide, the per-profile option is not shown and no profile can be anonymous. For configuration, see Access Profile Security Settings and Global Access Profiles Parameters.

Level 3 — Labels

Labels group Access Profiles under a common tag and add a layer of context-aware, hierarchical permission logic on top of individual profile settings.

What Labels Do

A Label is more than an organizational container. When a user is granted access to a Label, they gain visibility into all Access Profiles that belong to it and have inheritance enabled. This makes Labels the primary mechanism for managing access in bulk — instead of assigning permissions to dozens of individual profiles, an administrator assigns them once to the Label.

Hierarchy and Inheritance

Labels support a parent/child hierarchy. A parent Label can contain child Labels, and child Labels can contain Access Profiles at any depth. The inheritance chain works as follows:

• A Label inherits permissions from its parent Label by default.
• A Label passes those permissions down to its child Labels and to the Access Profiles within it (where inheritance is enabled).
• An Access Profile that has Inherit label access permissions disabled breaks the chain at that profile: its own explicit permissions apply regardless of the Label’s rules.

Permission on Labels

Directory groups can be assigned to a Label directly, avoiding the need to add each member individually. When a group such as Documenters is assigned to a Label, all members of that group inherit the Label’s permissions at once. The assignment also defines whether group members have standard access rights or administrative privileges over the resources in that Label.

Configuration Interfaces

The authorization model described above is surfaced across several interfaces, each oriented toward a different administrative role: