What problem are you having?
The example you are following uses a private key, associated to a service account, to sign a JWT and then send it to google to request a token. In my experience the most common problem is that when using the GenerateJWT policy, the privatekey is misformatted. This happens when the key material provided is not in a format that can be parsed.
To troubleshoot this, I suggest that you first embed the PEM-encoded key into an AssignMessage policy, like this:
<AssignMessage name='AM-SetPrivateKeyVariable'>
<AssignVariable>
<Name>private.privatekey</Name> <!-- must use private prefix here -->
<Value>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCrXfjCAfJR8K+9
2rvB67ZyaGRdvSn3+NZdcEOxl0IV4f7YK5PockjcQVmaTmj6XfS4X8OTWi8EbdLZ
yaVa9CVL7ex7XhGXifoqUZW2o93fPPm015JGLei8LZhMIxLYma7hrGqh19kk9mwI
...
oBnc5zrx3gR1tTtj8rqkK/E=
-----END PRIVATE KEY-----
</Value>
</AssignVariable>
</AssignMessage>And then refer to that variable in the policy configuration, as in
<GenerateJWT name='GJWT-1'>
<PrivateKey>
<Value ref='private.privatekey'/>
</PrivateKey>
...
You need to insure that the AssignMessage is attached so that it executes before the GenerateJWT policy.
It is not possible for you to directly specify the PEM-encoded private key within the GenerateJWT policy; validation of the policy will prevent you from embedding a secret (the private key) inside GenerateJWT. But if you use AssignMessage to set the variable, that passes validation.
The one common challenge with this is, the Service Account JSON file encodes the private key in a form like this:
"-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC1uwMZRLIHg3+p\nvydbrbavESq+SLAFWy8T8...o7cpY/zXBoQ==\n-----END PRIVATE KEY-----\n"
...which does not look very much like the multi-line string I showed above in the AssignMessage. The reason is: all of the newlines stored in the JSON file are encoded as \n - backslash-n. So you would need to use a text editor or some other mechanism to un-encode those newlines - essentially remove the outer quote marks, and then replace each of the \n sequences with an actual newline. Then insert the result of THAT into the AssignMessage policy I showed above.
Once that works, THEN you can try loading the same private key string into the KVM. And change your policy to refer to the variable you retrieve from KVM. Something like this:
<GenerateJWT name='GJWT-1'>
<PrivateKey>
<Value ref='private.extracted_private_key'/>
</PrivateKey>
...
I typically do not load JUST the private key into the KVM. Rather, I load the entire service account key .json file into the KVM. And then within the API proxy, shred that JSON file to extract its various properties. This gist shows how I do that.
At that point, the client id, the private key, the oauth token endpoint, and other claims from that JSON file are all available as context variables.
If you could provide more detail as to what is going wrong, we might be able to help.
LinkedIn
Twitter
