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

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

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:

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

Security

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’
RC0

success

  • Failed verification displays rc[-1] status
RC1

failed

  • 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

Certificates

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

Azure AD Side

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

KEMP Side

Settings configuration

 

KEMP22

KEMP SubVS configuration

SPSI

KEMP SSO configuration

AuzreAD

AAD Configuration

 

 

See it in action:

 

Br,
Joosua

And muchos Gracias for Tomi Koskis BURP knowHow!

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google photo

Olet kommentoimassa Google -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s