Hi @dchiesa1 , We are seeing below error while we try to generate JWE for a signed payload. Is there anything that we are missing?
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout continueOnError="false" enabled="true" name="JC-GenerateJWE">
<DisplayName>JC-GenerateJWE</DisplayName>
<Properties>
<Property name="key-encryption">RSA-OAEP-256</Property>
<Property name="content-encryption">A256GCM</Property>
<Property name="payload">{signed_payload}</Property>
<Property name="expiry">1h</Property>
<!-- the context variable "my_public_key" must hold a PEM-encoded RSA public key -->
<Property name="public-key">{private.publickey}</Property>
</Properties>
<ClassName>com.google.apigee.callouts.GenerateEncryptedJwt</ClassName>
<ResourceURL>java://apigee-callout-encrypted-jwt-20250403.jar</ResourceURL>
</JavaCallout>
Error:
ejwt_exception: java.lang.IllegalStateException: unable to read anything when decoding public key
ejwt_error : unable to read anything when decoding public key
Solved! Go to Solution.
@raghunathapalle wrote:
response has three sections separated by period. Is there a way to base 64 decode the response by using the period as delimited ? we see 1. JOSE Header 2. JSON Payload & 3. JWS Signature in the response so how do we handle the base 64 decode, verify signature only for the JWS signature & send the json payload back to the client app?
Well it sounds like the response payload (decrypted) is ... a JWS or JWT. Probably JWT.
You can use DecodeJWT to split and then base64-decode the header and payload. (Or DecodeJWS if it is a JWS) But neither of those policies verifies a signature , which you should do.
So I would suggest that you try VerifyJWT on the 3-part dot-separated thing. And somewhere in your environment, you need to have the information about how to get the public key to verify the signature. I don't know how to solve that, but maybe you do.
Assuming the public key is available on a JWKS endpoint, the configuration will look like
<VerifyJWT name='VJWT-1'>
<Algorithm>RS256</Algorithm> <!-- or whatever is appropriate -->
<Source>jwe_output</Source>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<PublicKey>
<JWKS uri="https://the.endpoint.for.your.jwks/keys"/>
</PublicKey>
<!--
other elements here
-->
</VerifyJWT>
Good, I'm glad you're making progress!
@raghunathapalle wrote:
We are using VerifyJWS to verify the signature using public key from partner after DecodeJWT. Hope the data is trust worthy after the verifyJWS.
YES. Either VerifyJWS or VerifyJWT will verify the signature, and after that policy succeeds, your API proxy can be assured that the claims are trustworthy.
@raghunathapalle wrote:
We are seeing that apigeex response flow is skipping the decrypt , Decode & verify for error response from partner(backend). Is there a way to consider 400 & 500 as valid backend errors & do the decrypt , Decode & verify ?
yes, surely.
You can either
Your choice.
ps: you do not need to decode AND VerifyJWS. In general, you should perform the DecodeJWS before VerifyJWS only if the DecodeJWS will give you some data from the header, than you need to perform the VerifyJWS.