{"id":2946,"date":"2019-08-12T11:04:24","date_gmt":"2019-08-12T01:04:24","guid":{"rendered":"https:\/\/ashleyknowles.com\/?p=2946"},"modified":"2019-08-12T11:04:25","modified_gmt":"2019-08-12T01:04:25","slug":"using-json-web-tokens-with-ca-api-gateway","status":"publish","type":"post","link":"https:\/\/ashleyknowles.com\/2019\/08\/12\/using-json-web-tokens-with-ca-api-gateway\/","title":{"rendered":"Using JSON Web Tokens with CA API Gateway"},"content":{"rendered":"\n

Over the past 3 years or so working in a software team that develops APIs\/integrations between many complex systems, we’ve seen the rise of the JSON Web Token. This humble little block of base64 encoded data is now at the core of most every API we build, and is heavily used in enforcing confidentiality and integrity in many different ways in our landscape. <\/p>\n\n\n\n

CA’s API Gateway product includes functionality out of the box to handle JSON Web Tokens. But it comes with some nuances. Having been the API Gateway SME across many projects, I’ve had to decipher every bit of how CA’s mysterious JSON assertions work.<\/p>\n\n\n\n

Public & Private Keys<\/h2>\n\n\n\n

First things first. Not all public keys are made equal!<\/strong> CA’s product is unable to ingest RSA public keys for use in JWTs; it currently only gives you the option to use a public key where you have a corresponding private key installed (wtf mate), or you have a valid x509 certificate for (eg. SSL)… This is hardly useful.<\/p>\n\n\n\n

To get around this, we use this little snippet to convert a perfectly good RSA public key into a JWK format – (.NET Core C#) Get RSA Public Key in JWK Format (JSON Web Key)<\/a><\/strong>. To use this in the CA gateway, we wrap the JWK into a JWKS format, creating a JSON array of keys, and storing this in a context variable. This context variable is then referenced in the Encode\/Decode Json Web Token assertion.<\/p>\n\n\n\n

Next; JWKS keys can have multiple uses; in the case of CA, the key use MUST be specified, and it is not appropriate to simply state that the use is for encryption AND signing; instead, if a key is usable for both, you must create two keys within the JWKS with all things equal, and set the use<\/em><\/strong> value to ‘enc’<\/em> or ‘sig’<\/em> appropriately. <\/p>\n\n\n\n

The result of both of these actions is shown below:<\/p>\n\n\n\n

{\n  \"keys\": [\n    {\n      \"e\": \"AQAB\",\n      \"kty\": \"RSA\",\n      \"alg\": \"RS256\",\n      \"n\": \"uObuBVbjcjxgv8cfRc3......\",\n      \"use\": \"sig\",\n      \"kid\": \"3494b1e786cdad092e423766bbe37f54ed87b22d\"\n    },\n    {\n      \"alg\": \"RS256\",\n      \"n\": \"uObuBVbjcjxgv8cfRc3......\",\n      \"use\": \"enc\",\n      \"kid\": \"60f4060e58d75fd3f70beff88c794a775327aa31\",\n      \"e\": \"AQAB\",\n      \"kty\": \"RSA\"\n    }\n  ]\n}<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Combining JWS & JWE<\/h2>\n\n\n\n
Creating JWT’s that are both signed and encrypted is actually simple with the CA API Gateway. Unfortunately, the reverse is complex as CA poorly documents that you must do this in multiple steps; unlike creating a JWS\/JWE token, there is not a single assertion approach for the reverse. <\/p>\n\n\n\n
The process is as follows:<\/p>\n\n\n\n
1. Decode Json Web Token\n<\/p>\n\n\n\n
  • Decrypts the token; specify the private key to use to decrypt<\/li>
  • The output is an unencrypted signed JWT (JWS)<\/strong><\/li>
  • Use the ${decryptedPayload.plaintext} variable to reference the unencrypted JWT<\/li><\/ul>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    2. Decode Json Web Token (again)<\/p>\n\n\n\n
    • Verifies the signature of the JWT (JWS)<\/li>
    • Use a JWKS for the recipient key!<\/li>
    • Use ${output.payload} to reference the data in the token<\/li>
    • “Fail on invalid signature” should<\/li><\/ul>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      <\/p>\n\n\n
      \n<\/ins>