Hosted lab services

Lab cases

Case labs explains the case itself: Start, resources, checkpoints and cleanup. The lab chooses which hosted service it uses. The services stop when the case ends or you lose the permissions needed to use it. Tenant administrators configure ordinary clients, scopes, resources and workload trust through the same management controls the rest of the tenant uses.

Each service runs the exercise the lab describes. You cannot upload your own code or choose an arbitrary destination for its requests.

The relying party

Register the callback shown for the case, exactly as shown, on its public client. Choose the requested scopes, including openid, and an application session of 5, 15, 30 or 60 minutes. The case's expiry can shorten it further.

A private one-use launch opens the application. Sign-in uses real tenant authorization, PKCE, browser-bound state and nonce, and validation of the signed ID token's issuer, audience and expiry. The server encrypts tokens and the PKCE verifier; the browser holds Secure, host-only cookies. Ending this application session and ending the tenant's sign-in session are separate actions.

Inspect storage and server session reads the browser's storage keys and current server session without showing tokens. A cached view can remain after the server session ends. These observations help diagnosis; they are not assertions that make a graded check pass. A lost redemption response remains unresolved and cannot redeem the code a second time.

The SAML receiver

Prepare the case's fixed service provider first. Use its returned entity ID, assertion consumer service (ACS) address and public request certificate in a normal SAML application. Add that application, the person who signs in and the tenant signing keys to the case under Resources in this case, with your current management permissions. The receiver cannot create those resources or sign anyone in on the tenant's behalf.

Select an application session of 5, 15, 30 or 60 minutes, clock skew of 0, 30 or 60 seconds, and whether the request requires a fresh tenant authentication. The application's supported NameID format, assertion lifetime and response-signing settings remain the tenant administrator's choices. This fixed service provider always signs AuthnRequests, so its public request certificate must be registered. The tenant may also require signed requests.

A one-use browser launch starts a real signed SAML AuthnRequest. The ACS accepts only the launched browser's pending response: it checks current tenant metadata and the signing certificates in the case, every supplied signature, the person, audience, destination, recipient, InResponseTo and time. Assertions must be signed. Acceptance, replay protection, the application session and the server's record are saved together. An assertion is one-use even across fresh requests.

The cross-site browser POST carries a host-only Secure HttpOnly admission cookie. The separate application session and CSRF cookies use SameSite=Lax. Assertion conditions limit when the response may be accepted. The application's separate session honors its selected lifetime, case expiry and any signed SessionNotOnOrAfter deadline; user changes, revoked signing authority and application changes are rechecked on use. Signing out ends this application's session. It does not send a SAML single-logout request to the tenant. Audit retains only resource IDs, the request ID, verified key IDs and an assertion digest, never raw XML, NameIDs or attributes.

Pipeline assertions

An active lab case has its own HTTPS issuer and public key set. Choose a fixed repository, branch and environment and an assertion lifetime of 60, 120 or 300 seconds. The signed assertion includes the attempt, client, tenant and generation as well as the selected workflow. Recreating a repository keeps its displayed name but changes its immutable repository ID.

Configure the client's federated workload credential with the issuer, audience, subject and conditions shown for the case. An exchanged token stays tied to the case and ends when the case or its current authority ends. Broader client scopes cannot let it read or change Sample API records outside the case.

Managed workload registrations

In OAuth Management, Clients, open a confidential client's row menu and choose Managed workload registrations. Select album inventory or photo manifest, optionally require one deployment version UUID, choose a signed lease assertion or certificate and holder-key proof, set a lifetime from 60 to 600 seconds, and choose whether renewal is allowed. A new registration is disabled until you enable it. BTL organization administrators use the same controls with their current organization permissions.

The task runs in the fixed hosted service, discovers the configured Sample API resource, exchanges its assertion, and reads only the case's album and photos. Its evidence records the deployment version, invocation, task and result digest. This establishes hosted workload lease assurance. It does not establish hardware, host, container or orchestrator attestation. Certificate mode creates a real expiring certificate and executes proof with its holder key; it does not claim a mutual TLS connection.

Renewal requires the current registration, selectors and lab case. A real hosted alarm renews about halfway through the delivered credential lifetime; its primary Audit identifies the hosted service separately from a learner's manual renewal. Editing or deleting the registration ends earlier access credentials. Apply an ordinary repaired registration's newer version through the same fixed workload controls; the prior credential is never reused. If a credential response is lost, the service retains an unresolved attempt and refuses blind start or renewal. End the case and press Start again for a fresh attempt.

The managed Labs check their own checkpoints. The first and healthy checkpoints verify the issuer signature and the token receipt, invocation and inventory. The automatic-renewal checkpoint requires the hosted alarm's Audit event ID and its stored receipt; a status read or manual renewal is insufficient. The expiry control verifies an original signed message as historical evidence and checks a real expired-token refusal while a renewed lease remains live. That comparison never authenticates an expired credential or extends its deadline. The checkpoint form keeps credentials transient, accepts only fixed references and diagnosis choices, and clears them on submission, refresh or context changes.

The management APIs are /api/auth/tenant/oauth/workload-registrations and the BTL organization counterpart /api/auth/admin/oauth/workload-registrations. GET lists one client selected by client_id. POST to /create, /update or /delete uses an idempotent command_id; updates also supply the current registration version. Reading and managing registrations have separate permissions.

Upstream outcomes

The fixed upstream can refuse one request, exceed a bounded deadline before an effect, or apply one fictional effect and lose its response. The caller retains the operation and command IDs. Unknown does not mean nothing happened: reconcile against the service's authoritative state before deciding whether to retry. A fresh command can retry only a recorded no-effect result. An applied operation never applies a second effect.

The recovery kit allocates fixed comparison IDs before any operation runs. Its receipts keep the original operation, revision, state and service receipt. A labeled simulated 429 has no limit policy. A separate explicit capacity control allocates only this attempt's bounded metadata, then proves its real registered operation-capacity rejection and current Usage row. It does not perform those capacity-only operations. The invalid-credential comparison uses the tenant's token endpoint once and proves nothing was sent upstream. These are fixed protected comparisons; no caller can supply an arbitrary destination, credential, fault script or verdict.

History, Usage and cleanup

In Audit, the source Hosted lab services shows the service's accountability records with action, actor, original case generation, resources and request references. Request Logs are collected diagnostics with status, duration and safe reasons. Each view needs its own current permission. Remote storage failure is shown as unavailable.

The tenant Usage view shows every attributable attempt's retained Audit records and cleanup reservations, upstream operations and browser state, with their limits and reset times. The registration capacity appears alongside ordinary tenant usage. Personal pipeline assertion pacing appears on Profile, Usage.

Ending or expiring a case removes private issuer keys, application sessions and fault authority. Known application credentials receive one recorded revocation attempt; unresolved external outcomes are not blindly repeated. Primary records remain for 30 days. Preserving tenant history retains its original generation; explicitly clearing tenant history needs the separate history-clear permission and never clears BTL security history.