SAML for your application is not enough !

If you have implemented authentication in your application using SAML, this will interest you. Although you might have not made the same mistake I did, but believe me, I thought this is out of the box functionality of ADFS or any other technology which issues SAML tokens.

Let me come to the point straight away. The SAML token issued by ADFS to my application was in plain readable XML format in my browser. I was astounded finding that I can read the entire SAML response in web debugging tool and there it was, all the information about me & my IDP. Pants!!! How the hell that happened? It took me around half an hour to recover and then I started digging.

First let’s just quickly understand how SAML works. I found this image online which is detailed enough to understand this protocol.

In steps:-

• Step 1: You try to access a secured website on your browser. In this case, saleforce.com.
• Step 2 & 3: Saleforce.com says, you are not authenticated and redirects you to let’s say your company’s active directory login page. This is a 302 Get redirect which you can see in your browser.
• Step 4 & 5: You provide your credentials at SAML identity provider and if valid, it redirects you back to salesforce.com with SAML token. This is now a 302 post redirect as it has the SAML token data.

And here lies my problem. I saw this step 4 & 5 302 post redirect in HTTPFox and there it was, my SAML token in plain XML in post data. See below:-

So today's new learning, by default, your SAML tokens are not encrypted between the identity provider & service provider.  You need to perform few more steps to make sure your tokens are encrypted and no one can see the assertions/attributes of your SAML token.

Now obviously, this only happens after successful login and people might argue that if some can login into your system then they already sort of bypassed the security but no. I blogged sometime back about how if you can fake claims then you can get into the application without IDP ever knowing about it. This SAML token contains assertions/attributes not only about the logged in user but also about your IDP and the type of trust your IDP & SP has. If hacker gets his hands on this token then your system is open to a logged in Bruteforce attack.

As I said, after I found this I started digging and here is the official documentation of OASIS on this. It clearly explains the type of SAML assertions, protocol and possible hacks which can be tried against them. The best practice of SAML communication is to encrypt the token. Even that is not going to save you from all sorts of hack but something is better than nothing.

After I found this, fixing the issue was not really a rocket science. All you have to do is upload the public key of your certificate (.cer) on your identity provider and install the certificate with the private key on service provider to make sure the SAML token can be decrypted when received here.

Now nothing is straight forward in IT and here also I have to do bit of RnD to make this working and below are the findings & best practices to do this:-

• First the certificate you will use for this must either be self-signed, or signed and chained directly to a public certification authority.
• Certificate files that contain only a public key (.cer file) must be DER-encoded. Base64-encoded certificate files will result in a validation error.

And finally, this is more of ADFS specific issue. I managed to get the assertions encrypted in the token but not the metadata and after bit more digging, I found, in active directory the default is to encrypt the assertions only and not the full message. You can change this if you have access to your AD which unfortunately not applicable in my case. If you wish to change this, use below command in powershell.

Set-ADFSRelyingParty -TargetName MyRP -SamlResponseSignature "MessageAndAssertion"

Once you do this, your SAML token will be completely encrypted and only readable by your SP & IDP. There would a slight impact on performance on your overall communication but I think when it comes to security, this is acceptable.

Remember, most of the things which are running and not being hacked so far is not because people can’t do it but because no one is trying J so always keep your application security at the max level you can.