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 a comprehensive scenario, and didn’t feel I need to cover more ground on KEMP’s SAML capabilities until now.

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 to switch the order so that Azure AD is directly IDP for KEMP.

The challenge was especially more interesting because according to 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.”

https://support.kemptechnologies.com/hc/en-us/articles/212736383-Feature-Description-SAML

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 a good question, I’ve covered using Azure AD App Proxy in another blog ’Azure AD’s best-kept secret’ for a 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: It's 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 other 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 a 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 similar kind of portfolio of features that KEMP covers.

I think this represents a 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. At the end (and acknowledging the overlapping features) I don’t see these solutions as pitted against each other completely, but more like synergy creating a mesh in the evolving market.

Configuration:

• Configuration requires Azure AD Premium P1 subscription to create an 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, it's just limited in bandwidth)

Security

I did a 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

success

• Failed verification displays rc[-1] status

failed

• Altered attributes in BURP

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

Say hello to my little friend

Certificates

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

Azure AD side

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

KEMP side

Settings configuration

KEMP SubVS configuration

KEMP SSO configuration

AAD Configuration

See it in action: