This blog attempts to capture some of the Single Sign-On and Authorization scenarios I’ve dealt with during my extensive tenure with Azure AD Application proxy deployments.
To keep this blog short there is no description of what Azure AD Application Proxy is generally. More information can be found here
- AAD SSO Column in the table indicates whether Single Sign-On setting on Azure AD Enterprise Application is enabled or disabled
- Native Clients in the following table assumes scenario where browser-like features (web view etc) are only used to perform subset of functions, such as authenticating user to Azure AD. All other calls are authorized to Azure AD Application via the usage of Access Tokens passed in Authorization Header
- For example: The native app may not use cookies to hold session persistence, but rather refresh token stored in the device
- Some native clients rely completely on running browser inside the app, or open external browser (payment views etc). In these scenarios the application may support similar option as described in the second column (2 Browser)
| Back-end Protocol | AAD SSO | 1 Native Client | 2 Browser | |
|---|---|---|---|---|
| SAML – WS/FED (SSO)* | Enabled:SAML / or Disabled* | No – At least when the most common binding: (Redirect -> POST) is used | Yes – 1.Further reading 2.Source | |
| Header Based Authentication against back-end API | Disabled | Yes – With Azure API management using JWT_Bearer Grant | Yes – With Azure API management using JWT_Bearer Grant (Note this solution is not for rendering browser views. To render browser view from API response additional client side rendering is required | |
| OAuth2 / OIDC | Disabled | No, unless the application is using web-view that maintains the session to Azure AD (source) | Yes – While existing Azure AD session is maintained within browser. Fetch/XHR, or redirect based client can make requests to the back-end app, which can then validate tokens in Authorization Bearer scenario (source) | |
| Header Based Authentication using PingAccess | Enabled:Header-Based | Not tested – Probably? (Refer to the documentation) | Not tested – Probably? (Refer to the documentation) | |
| Windows integrated Authentication / SPNEGO * * | Enabled:Windows Integrated Authentication | Yes – Kerberos Constrained Delegation by the App Proxy Agent is transparent to the client | Yes – Kerberos Constrained Delegation by the App Proxy Agent is transparent to the client | |
| Basic / NTLM Authentication * * * | Disabled | No – Authorization header is reserved for Bearer Tokens, which App Proxy Consumes | Yes – While existing Azure AD session is maintained within browser, Basic Authentication can be used. NTLM can be used as well, applies also to WIA scenario when WIA fallbacks to NTLM | |
| SOAP API (U/P) | Disabled | Yes – When credentials are passed as part of body, and authorization header contains the Bearer Token | Yes – When credentials are passed as part of body, and authorization header contains the Bearer Token | |
| Client Certificate | NA | No | No |
Clarifications
- * Existing IDP Session
- You could also have specified another Azure AD application separate from the App Proxy Enterprise Application. The SSO works regardless of the SSO setting, when the application uses sames IDP which the user has existing session on.
- * * About SPNEGO [Source]
- “If you configure a connector machine for SPNEGO, make sure that all other connectors in that Connector group are also configured with SPNEGO. Applications expecting standard KCD should be routed through other connectors that are not configured for SPNEGO “
- * * * Compound Authorization (in some cases Double authentication)
- First Authorization: Azure AD Consumes the Authorization header
- While Sending additional Bearer token in other than Authorization header, or in body payload
- Or While Sending additional Credentials in other than Authorization header, or in body payload
- Sequentially (after) challenged by the back-end app running in browser session
- First Authorization: Azure AD Consumes the Authorization header
Good to know
- Native API clients using AAD Pre-authentication
- With Native Clients Forwarding JWT tokens to back-end service doesn’t work unless the Native client is calling Azure AD App Proxy from webview like representation or pure browser
- Check also my blog regarding the options
- If you’d like to see “JWT forwarding in Authorization Header become available for non web view based clients” vote Forward incoming JWT token to backend service @AzureFeedback
- With Native Clients Forwarding JWT tokens to back-end service doesn’t work unless the Native client is calling Azure AD App Proxy from webview like representation or pure browser
- Only user identities can passed through application having Azure AD pre-authentication enabled
- For example Application identity (Client Credentials Flow) doesn’t work with Azure AD App Proxy Applications, unless Compound Authorization is used
- Apps can still work in chain (On-Behalf-of-Flow for example) as long as the identity being delegated is user identity
- If you have Windows Authentication enabled in the Application, ensure the deployment scenario supports Kerberos Constrained Delegation, and the Azure AD App Proxy agent can act as delegating party to the SPN.
- While Mutual TLS authentication isn’t supported features such as require device compliance from and other Client recognizing options are available when combined with Conditional Access.
- There are also other scenarios which I may cover in another blog post
- Using a mix of pre-authenticated and pass-trough Azure AD Applications
- Linked applications
- Password-based
Further reading
If you find any discrepancies (errors etc) with the information on the table just dm me at @santasalojoosua, or post question to this blog, and I shall correct it /explain it.
SecureCloudBlog 
0 comments on “Azure AD Application Proxy – SSO and Authorization notes from the field”