Visit our primer on SAML (pronounced like “SAM-El”; or “Sam’ll come eat when he’s hungry”) if you’re unfamiliar or just a little rusty.
Here are a few highlights:
SAML assertions are the proof of a user’s authentication, e.g., an assertion proves to applications that the user verified is who she says she is; and these assertions often include bits of information about the user that gives her access to certain things. For example, if we’re enabling SSO among apps for our hospital staff, apps might need to know if a nurse, doctor, or other hospital staff is trying to access medical records. We need to check that the user has been authenticated, and that they’re allowed access to the system, in other words, they’re authorized.
So where does this tool fit in? Yes, sorry, I’m getting there. The extra bits of information I talked about in the last section might be sensitive information, and we’re passing this assertion, which is essentially just an XML document, across the network to various apps with potential browsers or user agents facilitating the communication. Well, if a malicious user were to get their hands on the assertion, they’ll easily be able to read the information in it. How do we protect against these prying eyes? We encrypt the info!
That’s right, we are going to get all fancy with cybersecurity. Encryption protects the information from prying eyes by making it look like a jumbled mess of data that only certain parties can unscramble. A common way of encrypting is to use a secret, or a key. The IdP, the one generating these assertions, will use an algorithm with that secret to encrypt the information in the SAML assertion (we’re keeping it simple here folks). Then that key is shared with certain trusted parties who can then decrypt the encrypted data. Making sense?
This tool is made to help debug what’s going on in your SAML setup (since this requires inputting a secret, it’s wise to only use this for testing environments where the secret can’t be leaked and compromise valuable info or access, even though this app does all its work client-side). We often want to verify that the information in the SAML assertion matches with what we expect to be there.
It doesn’t help us to sit and stare at a scrambled jumble of numbers, letters, and other characters as if it were the world’s most challenging word search puzzle. We want to take a peek behind the door, and it requires the key to get in. What I’m getting at is, in order to decrypt an encrypted SAML assertion (or encrypted anything), a secret and the assertion is what’s needed. So, that’s exactly what this tool asks for. No more, no less.
The process only involves a few steps.
Input an encrypted, but decoded, SAML assertion in the first input box.
You can tell the difference because the encrypted and encoded assertion looks like one long string of random characters while the encrypted but decoded string will look like an XML document where you can read the actual tags.
If you have an encrypted and encoded SAML assertion, you can use our SAML Decoder tool to decode it.
Next, you’ll want to upload the secret stored in a file using the PEM format. The PEM format for the kind of key we’re looking for will start with the header “-----BEGIN PRIVATE KEY-----” and end with “-----END PRIVATE KEY-----”.
Click decrypt and out comes your decrypted SAML assertion!
Doesn’t handle unicode text very well.
Only one encrypted assertion node
It only decrypts if one of the aes-cbc algorithm was used.
*Although this tool runs client-side, since you’re inputting a secret, you should only use this with testing environments.