Federated identity
OIDC or SAML federation with strict issuer, audience, signature, state, nonce, and redirect handling.
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
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.
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.
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.