Azure AD Federation with KEMP

Joosua Santasalo

Joosua Santasalo

Senior Consultant, Digital Identity

May 23, 2018 at 15:40

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.

Azure AD_1_original-orderOriginal 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

Azure AD_2_new-orderUpdated 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

Azure_AD_3_rc0success

 

  • Failed verification displays rc[-1] status

Azure_AD_4_rc1failed

  • Altered attributes in BURP

Azure_AD_5_burp2

Azure_AD_6_burp2

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

 

Azure_AD_6_ugly-payload

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_7_signin

Azure AD side

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

Azure_AD_8_spsi2KEMP side

Settings configuration

Azure_AD_9_kemp22KEMP SubVS configuration

Azure_AD_10_spsi2KEMP SSO configuration

Azure_AD_11_azuread

AAD Configuration

See it in action:

Br,
Joosua

And muchos Gracias for Tomi Koski's BURP know-how!