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.

 

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 

 

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’

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

Certificates

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

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

Settings configuration

 

 

 

See it in action:

 

Br,
Joosua

And muchos Gracias for Tomi Koskis BURP knowHow!

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