ZTNA and identity-aware access

Goal

Protect an internal application so only authenticated, authorized users can reach it — without a VPN client.

Zero trust in one sentence

Instead of trusting a network location ("anyone on the VPN"), every request must prove who is making it, and policy decides per application who gets in.

How ShieldGate enforces it

1. A request arrives for a protected application.
2. The gateway checks for a valid session; without one, the user is sent to the identity provider to sign in.
3. After sign-in, the access policy is evaluated: user, group, and context conditions.
4. Only allowed requests are forwarded to the upstream; everything else never touches the app.

The upstream application can consume the forwarded identity headers instead of running its own login.

Steps

1. Configure the identity provider connection (OIDC) in the gateway settings.
2. Mark the application's route as protected.
3. Write the access policy: which users or groups may reach it.
4. Publish and test with an allowed and a denied account.

Verify

• Anonymous requests are redirected to sign-in.
• A user outside the allowed group receives a denial page, not the application.

Pitfalls

• Health checks and machine-to-machine callers need exemptions or service credentials — decide this before you protect a route that other systems call.