Azure AD Application Proxy – SSO and Authorization notes from the field

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 SSO1 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 APIDisabledYes 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 PingAccessEnabled:Header-BasedNot 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 CertificateNANo No


  • * 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

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
  • 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.

Azure AD Federation with KEMP

My earlier blog post ’The yellow box’ was about using AD FS as IDP and KEMP as SAML Service Provider. In that particular Blog I covered how KEMP was doing Pre-authentication, and then KCD to the back-end – It was quite comprehensive scenario, and didn’t feel I need to cover more ground on KEMP’s SAML capabilities until now.


Original order

Original scheme with AD FS

Azure AD as Direct IDP

Previously I was also using Azure AD for B2B identities, but with AD FS acting as sort of IDP proxy. This time I wanted switch the order, so that Azure AD is directly IDP for KEMP.

The challenge was especially more interesting, because according my short investigation it felt that this hasn’t been covered before – this was also the case in KEMP’s official documentation.

”Microsoft Active Directory Federation Services (AD FS) is the SAML-based Identity Provider (IdP) which has been tested and which is referred to in this document. However, other IdPs may also work.” 

new order

Updated scheme without AD FS


Bit of background before going through the configuration (or miniblog inside another blog…)

Q: Why not just use the Azure AD App Proxy?

A: Yes, that’s good question, I’ve covered using Azure AD App Proxy in another blog ’Azure AD’s best kept secret’ for similar scenario, and to be honest, I couldn’t say straight off the bat what to decide on this?

I would see that in larger enterprise both could be used for different scenarios:

The most fundamental principles are following:

AAD App Proxy: Its much easier to get going with AAD App Proxy due to its relatively easy and straightforward configuration. In some cases it requires about zero changes to networking. And it’s ”born in the cloud” or in another words, it sits in Azure AD, where you have API’s, users, and permissions out of the box

KEMP : Kemp can do both ”old” and ”new” stuff, meaning, that it does some classic reverse proxy tricks which can’t be found in AAD App Proxy (at the moment). It also does management of other products, and can use on-demand VPN tunnels to facilitate need for more back-end resources (That’s the new stuff anyway…)

If you would go ”Full-Azure” then you would need to publish some solutions with Azure Application Gateway, which is more of an classic reverse proxy. You would still need a third Azure solution (Azure Load balancer) if you need UDP protocol to be load balanced as well

So basically KEMP can do most of the stuff that the three separate Azure Products do, but you would need more components from Azure, if you would like to cover same kind of portfolio of features that KEMP covers.

I think this represents pretty good example of the hybrid landscape, where you have a lot of overlapping solutions, but might need to decide your approach on not just technical factors. In the end (and acknowledging the overlapping features) I don’t see these solutions as pitted against each other completely, but more like synergy creating mesh in the evolving market.


  • Configuration requires Azure AD Premium P1 subscription to create application with SAML integration.
    • I am keen to see, if KEMP would be interested to become first ADC vendor (that I know), to implement Azure AD authentication with the OpenID Connect Protocol
  • VLM-Free (Something that is great about KEMP, is that their free offering has pretty much all important features, its just limited in bandwidth)


I did an light co-op with my colleague @tomikoski to ensure that SAML Assertion Attributes can’t be altered in MITM -type scenario

  • We tested changing signature and usernames with BURP.
    • Changing either one, or both resulted in KEMP correctly informing about failed verification, and not thus authorizing access to the back-end resource
  • Successful verification displays rc[0] status with message ’Signature is OK’



  • Failed verification displays rc[-1] status



  • Altered attributes in BURP

Kuvaesitys vaatii JavaScriptin.

  • Displayname modification in the payload was also tested with bit of humor included- It was safe to say, that this resulted in the attacker  @tomikoski  not gaining access to the back-end resource.

Ugly Payload

Say hello to my little friend


  • SAML Assertion Signature verification from IDP side (Azure AD) – This is referred as SAML signing certificate on Azure AD


Azure AD Side

  • SAML Assertion Signature verification from SP side (KEMP) – This is referred as IDP signing certificate on Azure AD



Settings configuration



KEMP SubVS configuration


KEMP SSO configuration


AAD Configuration



See it in action:



And muchos Gracias for Tomi Koskis BURP knowHow!

Going beyond specification

A little while ago I wrote about impersonating Web Application Proxy to AD FS with KEMP’s simple header modification.

Since writing the blog in LinkedIn, I’ve received some queries whether this works when you wan’t to process advanced AD FS claim rules, for example based on the forwarded client IP?

While documentation available don’t state it’s possible, you can actually do it, by going bit beyond the normal specification with header injections.

Behind the scenes

AD FS host is expecting ’X-MS-Forwarded-Client-IP’ header from KEMP. If this header is not present in the request, and ’X-MS-PROXY’ is it will just assume client is from extranet – In this scenario you can’t use any advanced claim rules in AD FS, that would use the Public forwarded from client.

As you all might know, its pretty standard stuff to include the ’X-Forwarded-For’ header to requests terminated in the edge, then re-encrypted to back-end. Well… 🙂 we are going to use the same logic here, just apply it in a bit different way.

The trick

  1. Ask KEMP to add ’X-Forwarded-For (+ Via)’ in ’Add HTTP Headers’
  2. Ask KEMP to Copy ’X-Forwarded-For (+ Via)’ to header ’X-MS-Forwarded-Client-IP’

The result

Now forwarded Client IP’s are part of the requests, and can be applied in advanced claim rules.

In the example, I’ve set AD FS to bypass MFA for Partner IP, if Partner user terminates from certain Public IP . This all works now courtesy of header modification provided by KEMP

Hope this helps somebody substituting WAP with KEMP

Br, Joosua