Today someone asked if it were possible to Encrypt or Decrypt data using a policy in Apigee Edge.
Of course that’s possible - it’s just software, right? But there is no out-of-the-box policy that performs crypto of arbitrary data. But let’s constrain the goal a little bit further. Rather than saying “encryption”, what if we constrain it to “AES Encryption”?
Announcing the AesCrypto callout!
As with other custom policies we’ve published recently, this is open source code, released under the Apache 2.0 source license. Also, though we have released the Java source code, you CAN use this policy without compiling anything. It’s ready to use, just specify your configuration in the policy file, as with any other policy.
Check the Readme on that for full details on how to use the policy. The basic configuration is like this:
<JavaCallout name="Java-AesEncrypt1">
<Properties>
<Property name='action'>encrypt</Property>
<Property name='passphrase'>{request.queryparam.passphrase}</Property>
<Property name='encode-result'>base64</Property>
</Properties>
<ClassName>com.dinochiesa.edgecallouts.AesCryptoCallout</ClassName>
<ResourceURL>java://edge-callout-aes-encryptor-1.0.jar</ResourceURL>
</JavaCallout>
What this does:
No source property is specified, therefore this policy configuration will encrypt the message.content. Specifying the passphrase means that a key and IV will be derived using PBKDF2. There is no pbkdf2-iterations property, so the policy will use its default value of 128001 iterations. There is no salt specified, so the policy uses its default of “Apigee-IloveAPIs”. There’s no key-strength property, so the default of 128 bits applies. There is no mode specified, so CBC is used. The result is encoded via base64, and placed into the context variable “crypto_output”.
There are lots of options supported on the policy. Check it out. I’d love to hear your feedback here.
A couple notes:
- The PBKDF2 uses the method described in IETF RFC 2898 to derive a key and IV. It uses 128,001 iterations, but you can change that if you like. Deriving a new key every time you use the policy will mean that performance will be sub-optimal at high load. It will perform better at load if you specify the key explicitly, and do not ask the policy to perform the calculations to derive the key. You can specify the key directly as a hex-encoded string.
- It encrypts and decrypts. On encryption, you can configure the policy to encode the output in hex or base64. Upon decryption, you can even UTF-8 decode the clear text into a String.
I’d love to hear your feedback.