3.Network & Security¶

Authentication & Authorization¶

2 possible scenario:
- use a web framework / code your own
- rely on AppSvc Easy Auth:
App Svc Easy Auth:
- provide out-of-the-box authentication with federated identity providers
- can integrate with multiple login providers at the same time:
  - Azure AD
    - By default, any user in your Azure AD tenant can request a token for your application from Azure AD.
    - You can configure the application in Azure AD if you want to restrict access to your app to a defined set of users.
  - Facebook
  - Google
  - Twitter
  - Any OpenID Connect public endpoint
- When enabled every incoming HTTP request passes through it before being handled by your application code
- easyauth.dll module is loaded by every app svc workers
- it runs separately from your application code and is configured using app settings
- Possible to define the behavior of the auth flow:
  - Allow unauthenticated requests: defers authorization of unauthenticated traffic to your application code
  - Require authentication:
    - reject any unauthenticated traffic to your application
    - applies to all calls to your app
- Authentication flow:

Step	Without provider SDK (= srv directed flow)	With provider SDK (= clt directed flow)
1. Sign user in	Redirects client to `/.auth/login/<provider>`.	Client code signs user in directly with provider's SDK and receives an authentication token. For information, see the provider's documentation.
2. Post-authentication	Provider redirects client to `/.auth/login/<provider>/callback`.	Client code posts token from provider to `/.auth/login/<provider>` for validation.
3. Establish authenticated session	App Service adds authenticated cookie to response.	App Service returns its own authentication token to client code.
4. Serve authenticated content	Client includes authentication cookie in subsequent requests (automatically handled by browser).	Client code presents authentication token in `X-ZUMO-AUTH` header (automatically handled by Mobile Apps client SDKs).

Network features¶

Traffic type:
- Inbound: traffic going into your app
- Outbound: traffic getting outside from your app
IP addresses Multi-tenant vs ASE:
- Multi-tenant:
  - AppSvc share front ends so needs specific features to manage network I/O requirements
  - 5 virtual IP is assigned to a webspace (= a deployment unit hosting 1..n App Service):
    - 1 public inbound IP □*4 outbound IP
      - Selected randomly at runtime for every outgoing request
- ASE is directly integrated into a vnet so get static dedicated private ip address for I/O
I/O features by type of traffic:
- Inbound traffic related features:
  - Outbound IP address (et oui…)
  - App-assigned IP address
  - Access restriction
  - Service endpoints
  - Private endpoint
- Outbound traffic related features:
  - Outbound IP address
  - Hybrid connection
  - Gtw-required Vnet Integration
  - Vnet Integration
Network-related I/O features:
- (In and Out) Outbound IP address:
  - IP addresses allocated to the App Service
  - When you change the VM family (tied to tier), you get a different set of outbound addresses
  - Addresses are shared by all the apps running on the same worker VM family in the AppSvc deployment
- (In) App-assigned IP address (aka dedicated IP address):
  - Fixed IP allocated to the App
  - The address that's assigned to your app is used only by your app
- (In) Access restriction (IP based, Service Endpoint, Tag-based):
  - allow and deny rules that are evaluated in priority order
  - Applied on the front-ends
  - Up to 512 access restriction rules
  - Support for HTTP header-based restriction:
    - In preview as of 02/2021
    - Is an add-on to the different type of access restriction
    - Reduced list of available filtered header (not customizable)
    - 8 values per rule
  - Diffent type of restrictions:
    - IP-based restriction:
      - IPv4 & IPv6
      - ASE: vnet IP range
      - Multi-tenant: public Ips only
    - Service endpoints restriction:
      - = the source address reaching the service must come from a set of subnets that you select
      - works together (in conjunction) with IP access restrictions
      - Not compatible with remote debugging from selected subnet
    - Tag-based restriction:
      - In preview as of 02/2021
      - Filter traffic comming from specific Azure services
      - This can even be tied to an Azure Region
- (In) Private Endpoint:
  - Provide an IP address in a vnet for the resources to reach a multi-tenant App Service
    - Is a feature provided by Azure Private Link
    - Multiple Private Endpoints in others VNets and Subnets is supported
    - Can be deployed in a different region than the web app
    - Up to 100 PE per app
  - Once activated:
    - It disable the public access of the app
    - It disable the access restriction (rules are not evaluated)
    - It has a DNS impact:
      - The public DNS name of the app should still be used due to TLS certificate binding
      - Azure updates the CNAME record to point to a privatelink CNAME one:
        
        <app name>.azurewebsites.net resolves to <app name>.privatelink.azurewebsites.net
      - You need to create an Azure DNS private zone + 2 A-Records:
        
        privatelink.azurewebsites.net
        
        App: Add <app name>.privatelink.azurewebsites.net to resolves to PE IP
        
        Kudu: Add <app name>.scm.privatelink.azurewebsites.net to resolves to PE IP
  - Cannot filter by any NSG the access to your PE:
    - The NIC of the Private Endpoint cannot have an NSG associated
    - NSG on Subnet is OK but must disable NSG enforcement for the PE
  - Cannot be used to reach app in deployment slot
  - Cannot be used to remote debug the app
  - Only for inbound traffic (is not used by App Svc for outbound traffic):
    - From vnet
    - From peered vnet
    - From on-prem through ER private peering or VPN S2S
  - Only with tier: Isolated, PremiumV2, PremiumV3
- (Out) Hybrid Connections:
  - Allow to make outbound calls to specified TCP endpoints
    - The feature essentially tunnels TCP packets
  - Need to install a relay agent called Hybrid Connection Manager (HCM)
    - On Windows Server 2012 or newer host
    - HCM needs to be able to reach Azure Relay at port 443
  - To reach the TCP endpoint from App Svc:
    - DNS lookup for host and port is resolved to the hybrid connection
    - Traffic flows to Hybrid Connection Manager and get out of it
- (Out) Gateway-required Vnet Integration (aka old fashion Vnet Integration):
  - Allow to make outbound requests into/through a Vnet
    - Up to resources in peered Vnet
    - Up to resources hosted On-prem if path possible (through VPN only, not ER)
    - Doesn't work with ER-connected Vnet
    - Doesn't allow to send request to service endpoints-protected resources
    - Doesn't work with Linux App
    - Doesn't work with Windows Containers
  - The workers running the app connects to a Vnet through a P2S VPN connection
    - The Vnet should have a VPN Gateway up & running
    - The P2S address is allocated to each instance running the app
  - The app will use the targeted Vnet DNS server configured to resolve DNS lookup
- (Out) VNet Integration:
  - Allow to make outbound requests into/through Vnet
    - works by mounting virtual interfaces with addresses in the delegated subnet
      - 1 interface per worker
    - Vnet should be in the same Azure region
    - Vnet should dedicate an entire empty /28 or larger subnet for the integration
    - Subnet should be large enough to host max instances when scaling out ® /26 is the recommended size
  - Up to resources in peered Vnet
  - Up to resources hosted on-prem by either VPN or ER
  - Supported for reaching service endpoints-protected resources
  - Support NSG
  - Support UDR
  - Cannot be deployed in the same subnet where a private endpoint exists
  - Available in Standard and Premiums tier
  - By default only RFC1918 traffic from the app is routed into the Vnet
    - Set app settings WEBSITE_VNET_ROUTE_ALL to 1 to force tunneling all the traffic from the app
  - VNI is related to App Service Plan and is used by all the app in the plan (1..1 VNI/AppSvc Plan)
  - DNS impact:
    - Once integrated the apps use the DNS server of the Vnet
    - To use Azure DNS private zone to resolve names:
      - Set app settings WEBSITE_DNS_SERVER to 168.63.129.16
      - Set app settings WEBSITE_VNET_ROUTE_ALL to 1
  - The WEBSITE_PRIVATE_IP env var is accessible from the code to get currently worker-assigned IP address
Opened Inbound Ports:
- 80, 443: HTTP, HTTPS
- 454, 455: Management
  - = Azure Infra Ops team use
  - used by Azure infrastructure for managing and maintaining App Service Environments via TLS
- 21, 990, 10 001-10 020: FTP, FTPS
- 4020, 4022, 4024: VS Remote debugging
- 8172: WebDeploy service
- 7654, 1221: Infrastructure use
  - Metadata endpoint used by the internal service (does not take any input, only returns an IP address)
App Svc public DNS name resolution:
- The public name of a web app is a canonical name to the cluster where the app is hosted
- <app name>.azurewebsites.net resolves to <cluster name>.azurewebsites.windows.net
- <cluster name>.azurewebsites.windows.net resolves to <cloud service name>.cloudapp.net
- <cloud service name>.cloudapp.net resolves to the public IP address