An administration app is exposed publicly
A login page is the only barrier between the Internet and a sensitive upstream application.
PRIVATE APP ACCESS
Bring a private application to the right user without broad public exposure.
The Oten Gateway architecture places a resource-side Policy Enforcement Point in front of internal web applications and APIs. It validates identity and device context, applies route policy, and forwards only authorized requests under an explicit upstream contract.
System role: Oten Gateway + Access Control Plane
Evaluation depends on: Requires Gateway L7 enforcement, identity federation, Device Trust, and signed route policy.
SUBJECTUser + qualified deviceSession context
POLICYRoute decisionAllow · Step-up · Deny
PEPOten GatewayHeader boundary
RESOURCEPrivate applicationApproved upstream
Private applications fail safely only when the route contract is explicit.
A contractor needs one application
The business needs a bounded route without enrolling the contractor into the corporate network.
A legacy app trusts identity headers
Client-supplied or intermediary headers can impersonate a user unless the Gateway sanitizes and replaces them at the trust boundary.
A streaming session outlives policy
WebSocket or long-lived HTTP traffic requires its own refresh, close, and confirmation behavior after trust changes.
Every request crosses an explicit trust boundary.
Request
A user requests a protected application or API route.
Authenticate
Gateway establishes or validates a session through the configured identity provider.
Evaluate
Policy combines subject, group, device trust, route, authentication assurance, and configured conditions.
Decide
The result is Allow, Step-up, Restrict, or Deny with policy-safe reason codes.
Forward
Gateway forwards the request only after stripping untrusted identity headers and applying the approved upstream identity contract.
Audit
Subject, device, route, policy version, result, and correlation ID become one decision record.
Application access is scoped by route and session behavior.
Federated identity
OIDC or SAML federation with strict issuer, audience, signature, state, nonce, and redirect handling.
Per-resource policy
Route policy can require user group, device trust, authentication assurance, time, risk, or step-up.
Upstream identity
Protected headers are stripped or overwritten. Identity propagation follows an allowlisted upstream contract.
Session control
Idle lifetime, absolute lifetime, logout, and revoke semantics are defined separately from the IdP session.
Non-human access
Service identities use a dedicated pattern rather than impersonating interactive users.
Break-glass
Emergency routes are explicit, time-bound, strongly authenticated, and more heavily audited. They are not invisible bypasses.
Application onboarding has an owner, health contract, and rollback.
Define
Name the application, routes, methods, upstreams, resource owner, sensitivity, and supported session modes.
Integrate identity
Configure federation and the exact upstream header or service-identity contract, then test spoofing and sanitation.
Stage health
Verify certificates, DNS, network reachability, upstream health, logs, timeouts, and application-owner diagnostics.
Pilot policy
Move one route and cohort through Gateway with current identity and qualified device conditions.
Confirm and expand
Verify allow, step-up, deny, active-session behavior, health, and audit before adding routes.
Denied access should be safe and actionable.
- Show only a safe resource name that does not disclose internal topology to an unauthenticated user.
- Classify the reason as authentication, device, authorization, approval, or stale/expired context.
- Provide a request or correlation ID for support and audit.
- Offer remediation or a legitimate access-request path when one exists.
- Never display the raw policy expression, secret, internal IP address, or protected upstream header contract.
Continuous evaluation remains specific to the resource mode.
FAQ
Questions security and platform teams ask first.
Does Private App Access require the upstream application to be public?
No. Gateway remains near the protected resource and forwards authorized traffic to a private upstream under an explicit ingress and identity contract.
Can an application trust identity headers from the client?
No. Gateway must remove or overwrite protected headers at the trust boundary and emit identity only under a configured, authenticated upstream contract.
Will every active application session terminate when device trust changes?
New requests follow the re-evaluated policy decision. Active HTTP, WebSocket, streaming, SSH, database, and PAM sessions use their protocol-specific refresh or termination control. The audit record identifies the requested action and the confirmed session outcome.
Next in Oten Access
Continue the technical evaluation.
Protect application routes with explicit identity and device policy.
See how Gateway separates resource-side enforcement from relay services and broad network access.