{"id":1021,"date":"2026-06-04T21:05:54","date_gmt":"2026-06-04T21:05:54","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1021"},"modified":"2026-06-04T21:05:55","modified_gmt":"2026-06-04T21:05:55","slug":"complete-tutorial-guide-proxy-identity-aware-proxy-iap-aws-and-azure","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/complete-tutorial-guide-proxy-identity-aware-proxy-iap-aws-and-azure\/","title":{"rendered":"Complete Tutorial Guide: Proxy, Identity-Aware Proxy, IAP, AWS, and Azure"},"content":{"rendered":"\n

1. What is a Proxy?<\/h2>\n\n\n\n

A proxy<\/strong> is a server that sits between a client and another service.<\/p>\n\n\n\n

Instead of this:<\/p>\n\n\n\n

User \u2192 Application\n<\/code><\/pre>\n\n\n\n
you get this:<\/p>\n\n\n\n
User \u2192 Proxy \u2192 Application\n<\/code><\/pre>\n\n\n\n
The proxy receives the user request, checks or modifies it, and then forwards it to the real backend service.<\/p>\n\n\n\n
2. Types of Proxies<\/h2>\n\n\n\n
Proxy type<\/th>Direction<\/th>Main use<\/th><\/tr><\/thead>
Forward proxy<\/strong><\/td>Client \u2192 Internet<\/td>Used by users\/devices to access external websites through a controlled gateway<\/td><\/tr>
Reverse proxy<\/strong><\/td>Internet\/User \u2192 Internal app<\/td>Protects backend apps and exposes a controlled public endpoint<\/td><\/tr>
Load-balancing proxy<\/strong><\/td>User \u2192 Multiple backend servers<\/td>Distributes traffic across app servers<\/td><\/tr>
API gateway<\/strong><\/td>Client\/API consumer \u2192 APIs<\/td>Authentication, rate limits, API routing, request validation<\/td><\/tr>
Identity-aware proxy<\/strong><\/td>User \u2192 Protected app<\/td>Allows access only after identity and policy checks<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Most production \u201cproxy in front of app\u201d designs are reverse proxies<\/strong>.<\/p>\n\n\n\n
flowchart LR\n    U[User Browser] --> P[Reverse Proxy]\n    P --> A1[App Server 1]\n    P --> A2[App Server 2]\n    P --> A3[App Server 3]\n\n    P --> L[Logs \/ Monitoring]\n    P --> W[WAF \/ Security Rules]\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
3. What is Identity-Aware Proxy?<\/h1>\n\n\n\n
An Identity-Aware Proxy<\/strong>, often shortened to IAP<\/strong>, is a proxy that checks who the user is<\/strong> before allowing access to an application.<\/p>\n\n\n\n
A normal reverse proxy usually asks:<\/p>\n\n\n\n
\n
\u201cWhere should I route this request?\u201d<\/p>\n<\/blockquote>\n\n\n\n
An Identity-Aware Proxy asks:<\/p>\n\n\n\n
\n
\u201cWho is this user, are they allowed, is their device trusted, and should this request reach the app?\u201d<\/p>\n<\/blockquote>\n\n\n\n
Google Cloud has a product literally called Identity-Aware Proxy<\/strong>, which creates a central authorization layer for HTTPS applications and lets teams use application-level access control instead of depending mainly on network-level firewalls. Google describes IAP as a cloud-native alternative to traditional VPNs for apps on services such as Cloud Run, App Engine, Compute Engine, and GKE. (Google Cloud Documentation<\/a>)<\/p>\n\n\n\n
In AWS and Azure, the same pattern exists, but the product names are different:<\/p>\n\n\n\n
Cloud<\/th>IAP-style service<\/th><\/tr><\/thead>
Google Cloud<\/td>Identity-Aware Proxy<\/td><\/tr>
AWS<\/td>AWS Verified Access, or ALB authentication with Cognito\/OIDC<\/td><\/tr>
Azure<\/td>Microsoft Entra Application Proxy, App Service Authentication, Microsoft Entra Private Access<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
4. Why Use Identity-Aware Proxy?<\/h1>\n\n\n\n
Without IAP:<\/p>\n\n\n\n
flowchart LR\n    U[User] --> VPN[VPN \/ Network Access]\n    VPN --> NET[Private Network]\n    NET --> A[Internal App]\n    NET --> DB[Other Internal Systems]\n<\/code><\/pre>\n\n\n\n
The problem: once a user gets into the network, they may have broader network reach than they actually need.<\/p>\n\n\n\n
With IAP:<\/p>\n\n\n\n
flowchart LR\n    U[User] --> IAP[Identity-Aware Proxy]\n    IAP -->|Allowed request only| A[Specific App]\n    IAP -.->|Denied| D[Blocked]\n\n    IDP[Identity Provider] --> IAP\n    POLICY[Access Policy] --> IAP\n    DEVICE[Device Posture] --> IAP\n<\/code><\/pre>\n\n\n\n
The user gets access to one application<\/strong>, not the whole network.<\/p>\n\n\n\n
Key Benefits<\/h2>\n\n\n\n
Benefit<\/th>Explanation<\/th><\/tr><\/thead>
No broad VPN access<\/strong><\/td>Users access only the app they are authorized for<\/td><\/tr>
Central authentication<\/strong><\/td>Login is handled by IdP such as Google, Microsoft Entra ID, Okta, Cognito, Auth0<\/td><\/tr>
Central authorization<\/strong><\/td>Rules are managed outside the application<\/td><\/tr>
MFA support<\/strong><\/td>You can require multi-factor authentication before app access<\/td><\/tr>
Group-based access<\/strong><\/td>Allow only specific teams, such as DevOps, Finance, HR, Admin<\/td><\/tr>
Device-aware access<\/strong><\/td>Some platforms can check device compliance, risk, or security posture<\/td><\/tr>
Better audit logs<\/strong><\/td>Access attempts are logged before traffic reaches the backend<\/td><\/tr>
Legacy app protection<\/strong><\/td>Old apps can be protected without rewriting app authentication logic<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
5. How Identity-Aware Proxy Works<\/h1>\n\n\n\n
At a high level:<\/p>\n\n\n\n
sequenceDiagram\n    participant User as User Browser\n    participant IAP as Identity-Aware Proxy\n    participant IdP as Identity Provider\n    participant Policy as Policy Engine\n    participant App as Backend App\n\n    User->>IAP: Request app.example.com\n    IAP->>IdP: Redirect user to login\n    IdP->>User: Login page \/ MFA\n    User->>IdP: Credentials + MFA\n    IdP->>IAP: Token \/ identity claims\n    IAP->>Policy: Evaluate user, group, device, request\n    Policy-->>IAP: Allow or deny\n    alt Allowed\n        IAP->>App: Forward request\n        App-->>IAP: Response\n        IAP-->>User: App response\n    else Denied\n        IAP-->>User: Access denied\n    end\n<\/code><\/pre>\n\n\n\n
IAP Decision Inputs<\/h2>\n\n\n\n
Input<\/th>Example<\/th><\/tr><\/thead>
User identity<\/td>rajesh@example.com<\/code><\/td><\/tr>
Group membership<\/td>DevOps<\/code>, Admins<\/code>, Finance<\/code><\/td><\/tr>
Device posture<\/td>Managed laptop, compliant device, antivirus healthy<\/td><\/tr>
Location \/ IP<\/td>Company region, trusted IP range<\/td><\/tr>
MFA status<\/td>MFA completed or not<\/td><\/tr>
Request details<\/td>HTTP method, path, hostname<\/td><\/tr>
Time<\/td>Business hours only<\/td><\/tr>
Risk score<\/td>Suspicious login, impossible travel, compromised device<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6. Normal Proxy vs Identity-Aware Proxy<\/h1>\n\n\n\n
Feature<\/th>Reverse Proxy<\/th>Identity-Aware Proxy<\/th><\/tr><\/thead>
Routes traffic<\/td>Yes<\/td>Yes<\/td><\/tr>
TLS termination<\/td>Yes<\/td>Yes<\/td><\/tr>
Load balancing<\/td>Often<\/td>Sometimes<\/td><\/tr>
User authentication<\/td>Usually no<\/td>Yes<\/td><\/tr>
Group-based authorization<\/td>Usually no<\/td>Yes<\/td><\/tr>
MFA support<\/td>Usually no<\/td>Yes, through IdP<\/td><\/tr>
Device-aware policy<\/td>No<\/td>Often yes<\/td><\/tr>
Zero Trust friendly<\/td>Limited<\/td>Yes<\/td><\/tr>
Best for internal apps<\/td>Sometimes<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
7. Core Architecture Components<\/h1>\n\n\n\n
flowchart TB\n    subgraph UserSide[User Side]\n        U[User Browser]\n        D[User Device]\n    end\n\n    subgraph ControlPlane[Identity and Policy Control Plane]\n        IDP[Identity Provider]\n        MFA[MFA]\n        DIR[User \/ Group Directory]\n        POL[Policy Engine]\n        LOG[Audit Logs]\n    end\n\n    subgraph ProxyLayer[Identity-Aware Proxy Layer]\n        IAP[IAP \/ Access Proxy]\n        WAF[Optional WAF]\n        TLS[TLS Certificate]\n    end\n\n    subgraph AppLayer[Private Application Layer]\n        APP[Internal Web App]\n        API[Internal API]\n        DB[(Database)]\n    end\n\n    U --> IAP\n    D --> IAP\n    IAP --> IDP\n    IDP --> MFA\n    IDP --> DIR\n    IAP --> POL\n    IAP --> LOG\n    IAP --> WAF\n    IAP --> TLS\n    IAP --> APP\n    APP --> API\n    API --> DB\n<\/code><\/pre>\n\n\n\n
Components Table<\/h2>\n\n\n\n
Component<\/th>Purpose<\/th><\/tr><\/thead>
User\/browser<\/strong><\/td>Makes the request<\/td><\/tr>
Identity provider<\/strong><\/td>Authenticates user<\/td><\/tr>
Policy engine<\/strong><\/td>Decides whether access is allowed<\/td><\/tr>
IAP\/proxy<\/strong><\/td>Enforces the decision<\/td><\/tr>
Backend app<\/strong><\/td>Receives only allowed traffic<\/td><\/tr>
Audit logs<\/strong><\/td>Record allow\/deny events<\/td><\/tr>
WAF<\/strong><\/td>Optional extra layer for web attacks<\/td><\/tr>
DNS<\/strong><\/td>Routes app domain to proxy<\/td><\/tr>
TLS certificate<\/strong><\/td>Secures HTTPS traffic<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
8. Tools to Implement Identity-Aware Proxy<\/h1>\n\n\n\n
Cloud-Native Tools<\/h2>\n\n\n\n
Platform<\/th>Tool<\/th>Best use case<\/th><\/tr><\/thead>
Google Cloud<\/td>Identity-Aware Proxy<\/td>Native IAP for Google Cloud apps and some on-prem\/private apps<\/td><\/tr>
AWS<\/td>AWS Verified Access<\/td>Identity-aware access to corporate\/private apps without VPN<\/td><\/tr>
AWS<\/td>Application Load Balancer authentication<\/td>Basic web authentication using Cognito or OIDC before forwarding to targets<\/td><\/tr>
Azure<\/td>Microsoft Entra Application Proxy<\/td>Publish private\/on-prem web apps with Entra ID authentication<\/td><\/tr>
Azure<\/td>Azure App Service Authentication \/ Easy Auth<\/td>Add authentication to App Service, Azure Functions, APIs with little\/no app code<\/td><\/tr>
Azure<\/td>Microsoft Entra Private Access<\/td>Broader Zero Trust private access and VPN replacement pattern<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
AWS Verified Access provides secure access to corporate applications without VPN and evaluates requests in real time. AWS also supports authentication directly at Application Load Balancer using Cognito or OIDC before routing to applications. (AWS Documentation<\/a>)<\/p>\n\n\n\n
Microsoft Entra Application Proxy provides secure remote access to on-premises web applications, while Azure App Service Authentication, also called Easy Auth, provides built-in authentication and authorization for App Service and Azure Functions. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
Open-Source \/ Vendor Tools<\/h2>\n\n\n\n
Tool<\/th>Type<\/th>Notes<\/th><\/tr><\/thead>
oauth2-proxy<\/code><\/td>Open-source reverse proxy<\/td>Protects apps using OAuth2\/OIDC authentication<\/td><\/tr>
Pomerium<\/td>Identity-aware proxy<\/td>Zero Trust, context-aware access proxy<\/td><\/tr>
Cloudflare Access<\/td>SaaS \/ ZTNA<\/td>Identity-based access to private apps<\/td><\/tr>
Teleport Application Access<\/td>Access platform<\/td>Identity-aware access for apps, SSH, Kubernetes, databases<\/td><\/tr>
NGINX + OIDC module\/lua<\/td>Reverse proxy pattern<\/td>Powerful but needs careful configuration<\/td><\/tr>
Envoy + external authorization<\/td>Service mesh \/ proxy<\/td>Advanced pattern for microservices<\/td><\/tr>
Traefik ForwardAuth<\/td>Reverse proxy middleware<\/td>Can delegate authentication to another service<\/td><\/tr>
Authentik<\/td>Identity provider + proxy features<\/td>Useful in self-hosted environments<\/td><\/tr>
Authelia<\/td>Authentication gateway<\/td>Common for homelab\/internal app protection<\/td><\/tr>
Keycloak<\/td>Identity provider<\/td>Often paired with oauth2-proxy, NGINX, Pomerium, or custom apps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
oauth2-proxy<\/code> describes itself as a flexible open-source tool that can work as a standalone reverse proxy or middleware for OAuth2\/OIDC authentication. Pomerium describes itself as an identity and context-aware reverse proxy, Cloudflare Access is Cloudflare\u2019s ZTNA product, and Teleport Application Access supports secure access to private applications. (GitHub<\/a>)<\/p>\n\n\n\n
\n\n\n\n
9. Example IAP Use Cases<\/h1>\n\n\n\n
Use case<\/th>Example<\/th><\/tr><\/thead>
Protect internal dashboard<\/td>Grafana, Kibana, Prometheus, Jenkins<\/td><\/tr>
Protect admin console<\/td>\/admin<\/code>, Django admin, Rails admin<\/td><\/tr>
Protect staging app<\/td>staging.example.com<\/code><\/td><\/tr>
Replace VPN for web apps<\/td>Give users access to one app, not the network<\/td><\/tr>
Protect legacy app<\/td>App has weak\/no auth, IAP adds modern SSO<\/td><\/tr>
Contractor access<\/td>Allow external partner only to one app<\/td><\/tr>
Production support access<\/td>Require MFA and device compliance for prod tools<\/td><\/tr>
Secure APIs<\/td>Require identity before API requests reach backend<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
10. Example Architecture: Protecting Grafana with IAP<\/h1>\n\n\n\n
flowchart LR\n    Dev[Developer] --> DNS[dashboard.company.com]\n    DNS --> IAP[Identity-Aware Proxy]\n    IAP --> IdP[Okta \/ Entra ID \/ Google \/ Cognito]\n    IAP --> Policy[Access Policy: DevOps group only]\n    IAP --> Grafana[Private Grafana]\n    Grafana --> Metrics[(Metrics DB)]\n\n    IAP --> Logs[Audit Logs]\n<\/code><\/pre>\n\n\n\n
Policy idea:<\/p>\n\n\n\n
Allow access only when:\n- user is authenticated\n- user belongs to DevOps group\n- MFA is completed\n- device is compliant\n- request is for dashboard.company.com\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
11. Implement Identity-Aware Proxy in AWS<\/h1>\n\n\n\n
AWS does not call its service \u201cIAP.\u201d The closest AWS-native equivalent is AWS Verified Access<\/strong>.<\/p>\n\n\n\n
AWS Option A: AWS Verified Access<\/h2>\n\n\n\n
Use this when:<\/p>\n\n\n\n
Requirement<\/th>Good fit?<\/th><\/tr><\/thead>
Private corporate app access<\/td>Yes<\/td><\/tr>
Replace VPN for web apps<\/td>Yes<\/td><\/tr>
Identity-aware access<\/td>Yes<\/td><\/tr>
Device-aware access<\/td>Yes, depending on provider<\/td><\/tr>
App should stay private in VPC<\/td>Yes<\/td><\/tr>
Need policy-based access<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
AWS Verified Access evaluates each request using trust data from identity\/device providers and policies. Verified Access endpoints represent applications, endpoints can inherit group policy, and app-specific endpoint policies can also be attached. Policies are written in Cedar and evaluated against identity\/device trust data. (AWS Documentation<\/a>)<\/p>\n\n\n\n
AWS Verified Access Architecture<\/h2>\n\n\n\n
flowchart TB\n    U[Remote User] --> DNS[app.company.com]\n    DNS --> VA[AWS Verified Access Endpoint]\n\n    subgraph AWS[AWS Account \/ Region]\n        VA --> VG[Verified Access Group]\n        VG --> POL[Cedar Access Policy]\n        VA --> ALB[Internal Application Load Balancer]\n        ALB --> EC2[Private EC2 \/ ECS \/ EKS App]\n    end\n\n    IDP[IAM Identity Center \/ OIDC IdP] --> VA\n    DEVICE[Device Trust Provider] --> VA\n    VA --> LOGS[CloudWatch \/ S3 Logs]\n<\/code><\/pre>\n\n\n\n
AWS Verified Access Components<\/h2>\n\n\n\n
Component<\/th>Meaning<\/th><\/tr><\/thead>
Verified Access instance<\/strong><\/td>Main container for Verified Access configuration<\/td><\/tr>
Trust provider<\/strong><\/td>Source of identity or device trust data<\/td><\/tr>
Verified Access group<\/strong><\/td>Logical group of protected apps<\/td><\/tr>
Verified Access endpoint<\/strong><\/td>Represents one protected application<\/td><\/tr>
Policy<\/strong><\/td>Cedar rule deciding allow\/deny<\/td><\/tr>
Target app<\/strong><\/td>ALB, network interface, or private application endpoint<\/td><\/tr>
Logs<\/strong><\/td>Access records for auditing and troubleshooting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Verified Access trust providers send user\/device context to AWS Verified Access; this context can include user attributes such as email or group membership and device information such as patch or antivirus posture. AWS supports IAM Identity Center as a user-identity trust provider, and it also supports OIDC-based providers. (AWS Documentation<\/a>)<\/p>\n\n\n\n
\n\n\n\n
AWS Verified Access Step-by-Step<\/h2>\n\n\n\n
Step 1: Prepare the private application<\/h3>\n\n\n\n
Example target:<\/p>\n\n\n\n
Private EC2\/ECS\/EKS app\n\u2193\nInternal Application Load Balancer\n\u2193\nAWS Verified Access\n\u2193\nPublic HTTPS hostname\n<\/code><\/pre>\n\n\n\n
Your backend app should not be directly public. Keep it in private subnets or restrict direct access using security groups.<\/p>\n\n\n\n
Step 2: Configure identity provider<\/h3>\n\n\n\n
Common choices:<\/p>\n\n\n\n
IdP<\/th>Example<\/th><\/tr><\/thead>
AWS IAM Identity Center<\/td>Native AWS workforce identity<\/td><\/tr>
Okta<\/td>OIDC\/SAML enterprise login<\/td><\/tr>
Auth0<\/td>OIDC provider<\/td><\/tr>
Microsoft Entra ID<\/td>OIDC\/SAML provider<\/td><\/tr>
Amazon Cognito<\/td>User pool \/ OIDC-style login<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For the AWS-native path, use IAM Identity Center as a trust provider. AWS notes that IAM Identity Center for Verified Access must be an AWS Organizations instance, not a standalone account instance. (AWS Documentation<\/a>)<\/p>\n\n\n\n
Step 3: Create Verified Access trust provider<\/h3>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Trust Provider:\n  Type: User identity\n  Provider: IAM Identity Center or OIDC\n  Policy reference name: idp\n<\/code><\/pre>\n\n\n\n
The policy reference name<\/strong> matters because it becomes the context key used inside Cedar policies. AWS documentation says that if the policy reference name is idp123<\/code>, the context key becomes context.idp123<\/code>. (AWS Documentation<\/a>)<\/p>\n\n\n\n
Step 4: Create Verified Access instance<\/h3>\n\n\n\n
Verified Access Instance:\n  Trust provider: idp\n  Logging: enabled\n<\/code><\/pre>\n\n\n\n
Step 5: Create Verified Access group<\/h3>\n\n\n\n
Verified Access Group:\n  Name: internal-apps\n  Policy: shared access rules for many apps\n<\/code><\/pre>\n\n\n\n
Step 6: Create endpoint for the application<\/h3>\n\n\n\n
Verified Access Endpoint:\n  Domain: app.company.com\n  Type: load balancer\n  Target: internal ALB\n  Certificate: ACM public certificate\n  Group: internal-apps\n<\/code><\/pre>\n\n\n\n
AWS describes a Verified Access endpoint as representing an application. Each endpoint is associated with a Verified Access group and can inherit the group policy. (AWS Documentation<\/a>)<\/p>\n\n\n\n
Step 7: Add access policy<\/h3>\n\n\n\n
Example Cedar policy for IAM Identity Center group + verified email:<\/p>\n\n\n\n
permit(principal, action, resource)\nwhen {\n  context.idp.groups has \"c242c5b0-6081-1845-6fa8-6e0d9513c107\" &&\n  context.idp.user.email.verified == true\n};\n<\/code><\/pre>\n\n\n\n
Replace:<\/p>\n\n\n\n
idp\n<\/code><\/pre>\n\n\n\n
with your actual policy reference name.<\/p>\n\n\n\n
Replace:<\/p>\n\n\n\n
c242c5b0-6081-1845-6fa8-6e0d9513c107\n<\/code><\/pre>\n\n\n\n
with your real IAM Identity Center group ID.<\/p>\n\n\n\n
AWS recommends using IAM Identity Center group IDs rather than group names so the policy does not break when a group name changes. (AWS Documentation<\/a>)<\/p>\n\n\n\n
Step 8: Configure DNS<\/h3>\n\n\n\n
Create DNS record:<\/p>\n\n\n\n
app.company.com \u2192 Verified Access endpoint domain\n<\/code><\/pre>\n\n\n\n
Step 9: Test access<\/h3>\n\n\n\n
Test<\/th>Expected result<\/th><\/tr><\/thead>
Unauthenticated user opens app<\/td>Redirected to IdP<\/td><\/tr>
Authenticated but wrong group<\/td>Denied<\/td><\/tr>
Correct group + verified email<\/td>Allowed<\/td><\/tr>
Direct backend ALB access<\/td>Blocked by security group<\/td><\/tr>
Policy removed<\/td>Denied by default<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
AWS says Verified Access denies application requests by default until a policy is defined.<\/p>\n\n\n\n
\n\n\n\n
12. AWS Option B: Application Load Balancer Authentication<\/h1>\n\n\n\n
Use this when you want simpler authentication at the load balancer level.<\/p>\n\n\n\n
flowchart LR\n    User[User] --> ALB[Public ALB with Auth Rule]\n    ALB --> Cognito[Amazon Cognito \/ OIDC IdP]\n    ALB --> TG[Target Group]\n    TG --> App[EC2 \/ ECS \/ EKS App]\n<\/code><\/pre>\n\n\n\n
AWS Application Load Balancer can authenticate users using corporate or social identities before routing requests to applications. It can integrate with Amazon Cognito or an OIDC provider. (AWS Documentation<\/a>)<\/p>\n\n\n\n
ALB Auth vs Verified Access<\/h2>\n\n\n\n
Feature<\/th>ALB Authentication<\/th>AWS Verified Access<\/th><\/tr><\/thead>
Basic login before app<\/td>Yes<\/td>Yes<\/td><\/tr>
OIDC\/Cognito support<\/td>Yes<\/td>Yes<\/td><\/tr>
Central Zero Trust policy<\/td>Limited<\/td>Stronger<\/td><\/tr>
Device posture<\/td>No \/ limited<\/td>Supported via trust providers<\/td><\/tr>
Private-app VPN replacement<\/td>Not as complete<\/td>Yes<\/td><\/tr>
Best for<\/td>Simple web login<\/td>Enterprise app access<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
AWS ALB Authentication Steps<\/h2>\n\n\n\n
    \n
  1. Create an Amazon Cognito user pool or use OIDC provider.<\/li>\n\n\n\n
  2. Create an Application Load Balancer.<\/li>\n\n\n\n
  3. Create HTTPS listener.<\/li>\n\n\n\n
  4. Add listener rule: authenticate first, then forward to target group.<\/li>\n\n\n\n
  5. Configure callback URL in IdP\/Cognito.<\/li>\n\n\n\n
  6. Restrict backend security group so only ALB can reach the app.<\/li>\n\n\n\n
  7. Test login and logout behavior.<\/li>\n<\/ol>\n\n\n\n
    AWS recommends special CloudFront forwarding behavior if CloudFront is placed in front of an authenticated ALB, including forwarding all request headers to avoid cached authenticated responses being served after session expiry. (AWS Documentation<\/a>)<\/p>\n\n\n\n
    \n\n\n\n
    13. Implement Identity-Aware Proxy in Azure<\/h1>\n\n\n\n
    Azure has several IAP-style patterns. Choose based on where the app runs.<\/p>\n\n\n\n
    Azure Decision Table<\/h2>\n\n\n\n
    App location<\/th>Best Azure option<\/th><\/tr><\/thead>
    Azure App Service \/ Azure Functions<\/td>App Service Authentication \/ Easy Auth<\/td><\/tr>
    On-premises private web app<\/td>Microsoft Entra Application Proxy<\/td><\/tr>
    Broad private access \/ VPN replacement<\/td>Microsoft Entra Private Access<\/td><\/tr>
    Kubernetes \/ containers<\/td>Ingress + Entra ID\/OIDC, or external IAP tool<\/td><\/tr>
    Public app needing WAF + auth<\/td>App Gateway\/Front Door + app-level auth or Easy Auth<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    14. Azure Option A: Microsoft Entra Application Proxy<\/h1>\n\n\n\n
    Use this when your app is on-premises or private, and you want remote users to access it without opening inbound firewall ports.<\/p>\n\n\n\n
    Microsoft Entra Application Proxy provides secure remote access to on-premises web apps. Microsoft says users can access on-premises apps through an external URL or internal application portal after SSO to Microsoft Entra ID. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    Azure Application Proxy Architecture<\/h2>\n\n\n\n
    flowchart TB\n    U[Remote User] --> URL[External URL]\n    URL --> ENTRA[Microsoft Entra ID Login]\n    ENTRA --> CAP[Conditional Access \/ MFA]\n    CAP --> APPSVC[Application Proxy Cloud Service]\n\n    subgraph PrivateNetwork[Private Network \/ On-Prem]\n        CONN[Private Network Connector]\n        APP[Internal Web App]\n    end\n\n    APPSVC --> CONN\n    CONN --> APP\n\n    ENTRA --> LOGS[Sign-in Logs \/ Audit Logs]\n<\/code><\/pre>\n\n\n\n
    How Azure Application Proxy Works<\/h2>\n\n\n\n
    sequenceDiagram\n    participant User\n    participant Entra as Microsoft Entra ID\n    participant Proxy as App Proxy Service\n    participant Connector as Private Network Connector\n    participant App as On-Prem App\n\n    User->>Proxy: Open external app URL\n    Proxy->>Entra: Redirect for sign-in\n    Entra->>User: Login + MFA \/ Conditional Access\n    User->>Proxy: Sends token after successful sign-in\n    Proxy->>Connector: Forward authorized request\n    Connector->>App: Send request to internal app\n    App-->>Connector: App response\n    Connector-->>Proxy: Return response\n    Proxy-->>User: Show app\n<\/code><\/pre>\n\n\n\n
    Microsoft explains that Application Proxy includes a cloud service and a private network connector installed on an on-premises server. The connector uses outbound connections, so you do not need to open inbound firewall ports. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    \n\n\n\n
    Azure Application Proxy Step-by-Step<\/h2>\n\n\n\n
    Step 1: Prepare prerequisites<\/h3>\n\n\n\n
    Requirement<\/th>Example<\/th><\/tr><\/thead>
    Microsoft Entra tenant<\/td>Your Azure\/Entra organization<\/td><\/tr>
    App Proxy license support<\/td>Depends on tenant licensing<\/td><\/tr>
    Windows Server for connector<\/td>Server with network access to internal app<\/td><\/tr>
    Internal app URL<\/td>http:\/\/intranet.local<\/code><\/td><\/tr>
    External app URL<\/td>https:\/\/intranet-company.msappproxy.net<\/code> or custom domain<\/td><\/tr>
    Users\/groups<\/td>Finance<\/code>, DevOps<\/code>, Support<\/code><\/td><\/tr>
    Conditional Access<\/td>MFA, compliant device, location rule<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Step 2: Install private network connector<\/h3>\n\n\n\n
    Install the Microsoft Entra private network connector on a Windows Server that can reach the internal application.<\/p>\n\n\n\n
    The connector should be placed close to the app network. For production, use at least two connectors for high availability.<\/p>\n\n\n\n
    Microsoft notes that connectors are lightweight agents installed inside the private network. Connectors create outbound connections to Application Proxy and Private Access services, and connector groups can be used for high availability and traffic routing. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    Step 3: Publish the internal application<\/h3>\n\n\n\n
    In Microsoft Entra admin center:<\/p>\n\n\n\n
    Enterprise applications\n\u2192 New application\n\u2192 On-premises application\n\u2192 Configure Application Proxy\n<\/code><\/pre>\n\n\n\n
    Example settings:<\/p>\n\n\n\n
    Setting<\/th>Example<\/th><\/tr><\/thead>
    Name<\/td>Internal Grafana<\/td><\/tr>
    Internal URL<\/td>http:\/\/grafana.internal:3000<\/code><\/td><\/tr>
    External URL<\/td>https:\/\/grafana-company.msappproxy.net<\/code><\/td><\/tr>
    Pre-authentication<\/td>Microsoft Entra ID<\/td><\/tr>
    Connector group<\/td>Production-Connectors<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Microsoft\u2019s tutorial for Application Proxy covers installing\/verifying the connector and adding an on-premises application to the Microsoft Entra tenant. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    Step 4: Assign users or groups<\/h3>\n\n\n\n
    Assign only the users\/groups that need access:<\/p>\n\n\n\n
    Users and groups:\n- DevOps\n- SRE\n- Platform Admins\n<\/code><\/pre>\n\n\n\n
    Step 5: Add Conditional Access<\/h3>\n\n\n\n
    Example policy:<\/p>\n\n\n\n
    For app: Internal Grafana\nGrant access only when:\n- User is in DevOps group\n- MFA completed\n- Device is compliant\n- Sign-in risk is low\n<\/code><\/pre>\n\n\n\n
    Microsoft says Application Proxy can use Microsoft Entra Conditional Access, allowing richer policy controls before connections to the private network are established. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    Step 6: Test<\/h3>\n\n\n\n
    Test<\/th>Expected result<\/th><\/tr><\/thead>
    User not assigned<\/td>Access denied<\/td><\/tr>
    Assigned user without MFA<\/td>MFA challenge<\/td><\/tr>
    Assigned user with MFA<\/td>App opens<\/td><\/tr>
    Connector stopped<\/td>App unavailable<\/td><\/tr>
    Internal app down<\/td>Proxy reachable but backend fails<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    15. Azure Option B: Azure App Service Authentication \/ Easy Auth<\/h1>\n\n\n\n
    Use this when your application runs on:<\/p>\n\n\n\n
    Azure App Service\nAzure Functions\nAzure Web App\n<\/code><\/pre>\n\n\n\n
    Azure App Service provides built-in authentication and authorization, commonly called Easy Auth<\/strong>, and Microsoft says it can help secure web apps, REST APIs, mobile backends, and functions with little or no code. (Microsoft Learn<\/a>)<\/p>\n\n\n\n
    Easy Auth Architecture<\/h2>\n\n\n\n
    flowchart LR\n    User[User Browser] --> AppSvc[Azure App Service]\n    AppSvc --> Entra[Microsoft Entra ID \/ Other IdP]\n    AppSvc --> App[Your Application Code]\n    App --> API[Backend API]\n<\/code><\/pre>\n\n\n\n
    Easy Auth Step-by-Step<\/h2>\n\n\n\n
      \n
    1. Open your Azure App Service.<\/li>\n\n\n\n
    2. Go to Authentication<\/strong>.<\/li>\n\n\n\n
    3. Add identity provider.<\/li>\n\n\n\n
    4. Choose Microsoft Entra ID or another IdP.<\/li>\n\n\n\n
    5. Configure unauthenticated requests:\n