Two tenants, two audiences

Identity and access

Family and administrative access use separate route groups and authorization checks. Parents and invited adolescents share Entra External ID authentication but have different application permissions. The administrative router requires a workforce token with the Lanternina.Admin role for every operation. Each hub presents a key bound to its household.

Separate identities for parents and administrators

Entra External ID supports self-service parent registration. Administrative privilege comes from a separate workforce app registration, rather than a flag in the Cosmos container that an administrator edits. The privilege and the application data therefore have separate control planes and bootstrap paths.

The administrator's token carries the privilege in its roles claim. Parent and admin applications have different audiences, and the API checks the audience before application logic. Only a workforce token reaches the app-role check on administrative routes.

Household isolation

Parent routes resolve the household through the account associated with the validated subject. Portal routes resolve it through the invited membership and limit photograph access to that member's submissions. Device routes compare the key with the digest configured for the household in the URL; changing that URL cannot authorize another family.

Household records in Cosmos DB use family partitioning, and image archives use household paths. Invitations and memberships currently share one private Blob document with conditional writes and application-level access checks. That register is not physically partitioned by family. Adding a home requires provisioning a distinct key and its server-side household binding.

The code enforces household boundaries, but the system has only run in one home. Provisioning and operation across multiple households remain untested.

House authentication

The hub presents its device key in the X-Device-Key header over TLS. The API holds the Azure credential and performs model calls for page reading, reminder interpretation and activity continuation. Device routes return 503 until household key bindings are configured.

A hub therefore carries a credential for its household routes rather than a credential that can be replayed against the Azure subscription. This boundary makes cloud connectivity a requirement for page reading.

The API stores SHA-256 digests of random hub keys. Unknown households, missing keys and incorrect keys receive HTTP 403. Rotation replaces the digest; revocation removes the binding. A stolen key remains usable within its authorized household until revocation takes effect. This bearer-key scheme does not provide device attestation or mutual TLS.

Local peripherals

The hub provisions the camera and displays. Their normal traffic stays on the local network; they do not contain Azure service credentials or the hub's cloud API key. Their firmware and provisioning remain unchanged. Compromise can still expose Wi-Fi settings, local credentials or pending photographs. The camera's upload token can be used to impersonate it to the hub, and a compromised network device can send traffic to reachable services. Absence of Azure credentials limits direct cloud access; it does not eliminate local risk.

Hardware-backed enrollment: proposal

A future hub could register through a short-lived, single-use invitation created by its parent. It would generate a signing key inside a TPM, prove possession and provide verifiable key attestation. The server would bind the device to the invitation's household and issue a client certificate. Subsequent access would use mTLS or a standard key-bound proof-of-possession mechanism, with renewal and parent revocation. A normal copyable bearer token would not provide the same protection.

This proposal is not implemented: the hub still uses a household-bound key. Compatible hardware and attestation support need verification. A non-exportable key would reduce cloning risk but would not prevent compromised software from using the TPM to sign.

Invited adolescent access

The parent creates an email-bound invitation and shares its code or link. The adolescent signs in with the matching address and accepts the invitation. Registration alone grants no portal access. An active membership permits submitting, listing and deleting that member's photographs, not approving activities or changing household settings. Revocation closes subsequent portal requests. Known adolescent subjects, including revoked memberships, are excluded from the parent gate. Suspension of the inviting parent also closes portal access.

The portal uses the existing External ID application and audience. Its permissions come from the server-side membership, not from a separate adolescent token audience. First registration and redemption with a real invited account remain a family acceptance check.

Application boundaries

The administrative router is registered separately and applies its authorization check to every route under /api/admin. Individual operations also request the verified administrator when they need to record who acted. Family routes retain their own account and household checks. The groups still share a process, deployment and runtime identity, so a process compromise or resource exhaustion can affect both. Service isolation would require a separate administrative service with independently restricted permissions and access controls.

Activity approval

The panel stores parent decisions. The hub retrieves approved activities through authenticated HTTPS and chooses when to begin. Continuations are checked and screened in the container but receive no second parent approval.

OIDC deployment

GitHub Actions exchanges its OIDC token for an Azure token through a federated credential on a user-assigned managed identity. Three resource-scoped role assignments allow the pipeline to push to one registry, read that registry and update one container app.

Known authorization gaps

The token validator checks audience, issuer, expiry and subject but omits scp. The current app exposes one scope. Adding another scope would require a scope check before it could separate permissions.

Configuration and deployment ·hub credential provisioning and revocation ·the pipeline's federated identity · what leaves the device

This site sets no cookies, collects no statistics, and loads nothing from anybody else's server.