Technical overview of the platform

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

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

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.

Assignment and policy checks

Before a launch path is opened, the server evaluates whether the requesting user holds an active assignment to the target resource within the current tenant context. Policy checks including group membership, time-of-day constraints where configured, and administrator-defined eligibility rules are resolved server-side. The portal UI reflects the result of these checks but does not serve as the enforcement boundary; denied assignments produce no connectable session path.

Session routing model

Once an assignment is verified, the secure access layer brokers a session path toward the approved target. Routing decisions consider the target type, tenant-level configuration, and the delivery model (browser-contained or client hand-off). Sessions are scoped to the individual assignment rather than granting broad network-level connectivity to the target environment's subnet.

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 handled by portal

The portal persists tenancy metadata, user-to-resource assignments, administrator-defined policies, integration configuration for identity and directory providers, and audit-oriented event records needed for administration and compliance reporting. Session launch metadata is retained to support troubleshooting and usage visibility. All stored data is scoped to the owning tenant partition.

Data not stored by portal

The portal does not store end-user desktop file contents, clipboard payloads, keystrokes, or screen captures from remote sessions. Credential material used to authenticate into target environments is not persisted in web-tier databases or logs. Remote-session pixel streams traverse purpose-built relay paths and are not recorded or archived by the portal layer.

Secrets handling

Integration secrets such as directory connector credentials and identity-provider client secrets are stored using controlled storage patterns with encryption at rest. They are not embedded in client-side bundles, rendered in portal HTML, or written to application logs. Access to secrets is restricted to the service components that require them at runtime.

Logging and audit events

The platform emits structured audit events for authentication outcomes, assignment changes, session launches, administrative actions, and policy modifications. Logs are tenant-scoped and available to authorized administrators through the portal or via export to customer-operated monitoring stacks. Sensitive credential material is excluded from log payloads by design.

Deployment models

MyWorkspace supports three deployment postures. Connect mode brokers access to existing office PCs and on-premises infrastructure without relocating workloads. Cloud Workspace mode provisions managed desktop environments hosted in cloud infrastructure. Hybrid mode combines both, allowing organizations to present on-premises and cloud-hosted resources through a single portal and assignment model. The choice of model is a tenant-level configuration decision.

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.

Customer-specific architecture review

Organizations with specific compliance, regulatory, or infrastructure requirements can request a dedicated architecture review. These sessions cover tenant topology, network integration, identity-provider configuration, and deployment-model selection in a controlled channel with the engineering team. Contact the team to schedule.

Security limitations and assumptions

The portal assumes that the customer's identity provider is correctly configured and that administrator accounts are protected by strong credentials and multi-factor authentication. Browser-contained sessions depend on the security posture of the end-user's browser and operating system. The platform does not claim to mitigate threats that originate from a fully compromised administrator account or a fundamentally broken identity provider. Customers are responsible for endpoint security policy on their managed devices.

Support and incident contact path

Production incidents and support requests are handled through the designated support channel provided during onboarding. Security-sensitive reports can be submitted through the contact page with appropriate handling expectations. Escalation paths and response-time commitments are defined in the customer's service agreement.

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.