Developers & IT

Technical overview of the platform

This page summarizes how the service is reasoned about in production: layered controls, least privilege, tenant scoping, explicit trust boundaries, and separation between the browser, the portal, the secure access edge, and target environments. It is descriptive—not a deployment runbook—and avoids naming specific commercial products where a capability-level description is enough.

Who this is for

Solution architects, security reviewers, platform engineers, and IT operators who need a credible mental model before a deeper engagement. If you require contractual diagrams or tenant-specific topology, that belongs in a controlled channel—not on a public page.

Major components (conceptual)

End users interact through a standards-based browser session to a web portal that hosts authentication flows, policy-aware navigation, and launch surfaces for assigned resources. Behind that sits application logic for tenancy, identity lifecycle hooks, and orchestration toward remote execution paths. A separate secure access layer terminates browser-oriented protocols, validates assignments and policy at connection time, and bridges toward office PCs, hosted desktops, cloud workspaces, or application tiers—without collapsing those environments into the portal’s trust domain.

Workspace presentation model

Assigned resources surface through the tenant portal as governed launch targets rather than raw network destinations. Administrators attach users to concrete offerings — commonly modeled as work apps, remote workspace entry points, office PCs, hosted desktops, operating-system environments, or internal applications. When a user starts a launch, workload execution remains associated with the approved target while interaction flows through a browser-contained session surface where that is the configured path. Where policy and integration require a different delivery model, the same assignment model can hand off to an approved client path instead of presenting entirely inside the browser. The important boundary is that the endpoint acts as an access surface rather than the execution environment itself. That separation allows organizations to expose Windows, Linux, macOS, server-hosted, cloud, or hybrid targets through one portal and assignment model without collapsing user devices into the internal network trust boundary.

High-level launch flow

  1. The user signs in to the tenant-scoped portal (multi-factor authentication applies where policy requires it).
  2. Tenant context is resolved for the session so subsequent checks apply to the correct configuration and data partition.
  3. Assignments and authorization are evaluated on the server before any remote path is prepared.
  4. Eligible resources—such as assigned work apps and the remote workspace experience—are presented in the portal UI.
  5. The user initiates a launch action for a chosen assignment.
  6. The secure access layer brokers an authorized session path that matches the assignment and tenant rules.
  7. The target environment becomes reachable through the browser-oriented surface or the configured client hand-off, depending on launch type.
  8. Access remains scoped to the approved assignment rather than implying blanket network access from the endpoint.

What runs where

Endpoint / browser

  • Authenticates the user to the tenant portal and maintains the web session.
  • Renders navigation, assignments, and launch controls (including the remote workspace area).
  • Carries user input and viewport instructions toward brokered session paths.
  • Receives the browser-contained remote experience when that is how the assignment is delivered.
  • Does not, by default, become a full trusted extension of the corporate LAN solely because a session is active.

Remote environment / target

  • Hosts the desktop, application, or workload the assignment points at.
  • Retains execution state and environment-specific authentication where applicable.
  • Is reached only through launch paths that were authorized for that user and tenant.
  • Stays logically outside the portal’s trust domain; the portal orchestrates access rather than co-hosting the workload.

Control plane / access layer

  • Resolves tenant scope and reads assignment data from tenant-partitioned stores.
  • Enforces authorization and launch eligibility server-side.
  • Brokers session establishment toward approved targets through the secure access layer.
  • Keeps connectivity scoped to the assigned resource instead of promoting flat network reach.

Environment types

MyWorkspace is designed around assigned environments rather than one fixed desktop type. Depending on tenant configuration, users may interact with full desktop environments, application-oriented workspaces, office-device entry points, server-backed environments, or browser-contained operational surfaces exposed through the same access model.

  • Office PCs
  • Windows desktop environments
  • Windows Server environments
  • Linux environments
  • macOS environments
  • Cloud workspaces
  • Internal applications

Runtime path at a glance

  1. Step 1: User browser
  2. Step 2: Tenant portal
  3. Step 3: Assignment + policy resolution
  4. Step 4: Secure access layer
  5. Step 5: Assigned target / environment
  6. Step 6: Browser-contained session
  1. User browser
  2. Tenant portal
  3. Assignment + policy resolution
  4. Secure access layer
  5. Assigned target / environment
  6. Browser-contained session
The endpoint remains an access surface while the approved workload stays associated with the assigned remote environment.

Identity, sessions, and authorization

Users authenticate to the tenant-scoped portal. Session semantics follow modern web practices (short-lived credentials at the edge, server-side validation for privileged actions). Role and assignment checks resolve on the server before a launch path is granted; the UI does not serve as the enforcement root of trust for remote connectivity. Multi-factor authentication is integrated where policy requires it; recovery and administrative flows are separated from standard user journeys.

Tenant isolation

Operational data is partitioned per tenant at the persistence and configuration layers. Cross-tenant paths are rejected by construction in control-plane APIs; runtime launches resolve only within the caller’s tenant context. Where shared infrastructure exists, isolation relies on explicit application tenancy and infrastructure boundaries—not on obscurity.

Transport and edge posture

Traffic uses encrypted transports between clients and service endpoints. The browser-facing tier does not assume a legacy VPN client on the endpoint; connectivity toward internal or hybrid targets is brokered through components designed for outbound-initiated, authenticated sessions rather than broad network flattening. Exact cipher suites and TLS versions follow production security baselines and change with maintenance windows.

Data handling (high level)

The portal stores tenancy metadata, assignments, audit-oriented events needed for administration, and integration configuration appropriate to the product surface. Secrets for third-party connectors are handled through controlled storage patterns—not embedded in client bundles. Remote-session payloads traverse purpose-built paths; credential material for target environments remains scoped to the remote session boundary rather than duplicated into web-tier logs by design.

Observability and operations

Platform operators rely on structured logging, health endpoints, and capacity signals suitable for enterprise monitoring stacks. Customer-visible incidents are communicated through agreed channels; deeper operational diagnostics are handled through controlled support and review channels.

Extensibility

Integrations favor stable HTTP APIs and standard identity protocols where customers expect interoperability (for example directory or SSO-oriented flows at a high level). Feature flags and staged rollout hooks allow tenants to adopt capabilities without jeopardizing isolation guarantees.

Public page boundary

This page describes the platform at a capability and boundary level. Tenant-specific topology, integration details, deployment diagrams, and sensitive operational paths are reviewed in controlled channels.

If you have other questions, see the FAQ.

For product-level positioning and FAQs, see the main Technology page; for commercial questions, use Contact.

If you have other questions, see the FAQ.