How does the new Policy for JWE work?

https://community.apigee.com/questions/87728/does-apigee-supports-jwe-and-encryption.html?childToVie...

The answer to above post is exactly what I was trying to implement following the links here - https://github.com/apigee/iloveapis2015-jwt-jwe-jws

I had a custom callout too, that I was trying to port on the APIGEE.

I have 3 questions regarding this new policy.

1) The policy may use AES256 algorithm. Does APIGEE uses default Security provider mentioned in JDK 8 to support the JCE unlimited strength jurisdiction policy? the reason I'm asking because Jose4j (https://bitbucket.org/b_c/jose4j/wiki/Home) requires the JCE's Unlimited Strength Jurisdiction Policy Files.

2) So, if I have to Generate a JWT (JWS), and sign it (JWE) as well.. Do I need to append the two instances of GenerateJWT policy? One for generating the JWT (JWS), and use the outcome of that as Input to above Policy to create the JWE?

3) Does above policy also supports Direct symmetric Encryption and Decryption (as mentioned in Jose4J example here). I wanted to use a Shared secret ..instead of dynamically generating a CEK.

Solved Solved
0 4 736
1 ACCEPTED SOLUTION

I have 3 questions regarding this new policy.

Just to be careful and clear, the VerifyJWT and GenerateJWT policies are not new; instead, the capability to verify or generate encrypted JWT is a recently added capability to the existing built-in policies.

1) The policy may use AES256 algorithm. Does APIGEE uses default Security provider mentioned in JDK 8 to support the JCE unlimited strength jurisdiction policy? the reason I'm asking because Jose4j ( https://bitbucket.org/b_c/jose4j/wiki/Home) requires the JCE's Unlimited Strength Jurisdiction Policy Files.

The builtin policies are enabled with unlimited strength crypto, yes.

2) So, if I have to Generate a JWT (JWS), and sign it (JWE) as well..

Let me stop you there. "Generate a JWT" implies either generating a signed JWT, or generating an encrypted JWT. It is not correct to suggest that JWE is used for signing. JWE is a IETF standard that describes how to wrap an encrypted payload in a JSON envelope. It is not about signing.

Do I need to append the two instances of GenerateJWT policy? One for generating the JWT (JWS), and use the outcome of that as Input to above Policy to create the JWE?

You should not append or concatenate JWT together. That's not how JWT or JOSE works. If you are composing signing and encrypting, a common approach is to sign a JWT, resulting in a longish string, and then use THAT STRING as the input to a JWE. This is not the same as concatenation. It is 2 different transforms: signing, then encryption. The result is a single long string.

3) Does above policy also supports Direct symmetric Encryption and Decryption (as mentioned in Jose4J example here). I wanted to use a Shared secret ..instead of dynamically generating a CEK.

Yes; direct key is supported. But, unfortunately, the encryption capability is not yet documented. We had a bit of a problem coordinating the release of the capability, with the update of the documentation of that capability . The prior post that you referenced, is... perhaps the best source of information on how to use the policy. It includes information on how to specify a Direct Key.

LMK if more questions.

View solution in original post

4 REPLIES 4

My questions were about the new policy.

I have 3 questions regarding this new policy.

Just to be careful and clear, the VerifyJWT and GenerateJWT policies are not new; instead, the capability to verify or generate encrypted JWT is a recently added capability to the existing built-in policies.

1) The policy may use AES256 algorithm. Does APIGEE uses default Security provider mentioned in JDK 8 to support the JCE unlimited strength jurisdiction policy? the reason I'm asking because Jose4j ( https://bitbucket.org/b_c/jose4j/wiki/Home) requires the JCE's Unlimited Strength Jurisdiction Policy Files.

The builtin policies are enabled with unlimited strength crypto, yes.

2) So, if I have to Generate a JWT (JWS), and sign it (JWE) as well..

Let me stop you there. "Generate a JWT" implies either generating a signed JWT, or generating an encrypted JWT. It is not correct to suggest that JWE is used for signing. JWE is a IETF standard that describes how to wrap an encrypted payload in a JSON envelope. It is not about signing.

Do I need to append the two instances of GenerateJWT policy? One for generating the JWT (JWS), and use the outcome of that as Input to above Policy to create the JWE?

You should not append or concatenate JWT together. That's not how JWT or JOSE works. If you are composing signing and encrypting, a common approach is to sign a JWT, resulting in a longish string, and then use THAT STRING as the input to a JWE. This is not the same as concatenation. It is 2 different transforms: signing, then encryption. The result is a single long string.

3) Does above policy also supports Direct symmetric Encryption and Decryption (as mentioned in Jose4J example here). I wanted to use a Shared secret ..instead of dynamically generating a CEK.

Yes; direct key is supported. But, unfortunately, the encryption capability is not yet documented. We had a bit of a problem coordinating the release of the capability, with the update of the documentation of that capability . The prior post that you referenced, is... perhaps the best source of information on how to use the policy. It includes information on how to specify a Direct Key.

LMK if more questions.

Hi Dino,
How can I go about implementing signed and encrypted JWT similar to the java implementation in below link Nested signed and encrypted JSON Web Token (JWT)

I see that you have implemented java callout for encrypted JWT for non-JSON encrypted payloads - is there way to implement this with apigee JWT/JWS policies instead of java callout. https://github.com/DinoChiesa/ApigeeEdge-CustomPolicy-EncryptedJWT

is there way to implement this with Apigee JWT/JWS policies instead of java callout

Still today, there is not a built-in policy that generates an arbitrary JWE. So if you want a JWE and not an encrypted JWT, for now you must rely on the Java callout to perform the encryption part.

Conveniently enough, I produced a screencast a couple weeks ago on this topic. And the repo you cited includes a sample bundle with a flow that demonstrates how to perform that work.