Generation of JWT using a Web Services Before Operation Rule and Private Key on VA

Hi, hoping to get some input on possible approaches for the use case below:
Use Case:

IDN needs to communicate to an end system using via an API for identity management operations. The system requires a private public key pair to be generated with the public key pair imported on the end system’s keystore.

IDN must then generate a JSON web token with the following context:

Header:
{
“alg”:RS256
}

Payload:
{
“iss”: name of the user who holds the public key in the app’s user store,
“exp”: token expiry,
“aud”: the API endpoint the token is meant to be used for, (will vary per API request)
“iat”: time of token issue
}

The JWT then needs to be signed with private key and sent along with the API request. Unfortunately the application does not offer any endpoints that can be leveraged to generate a JWT via the API.

Is there a away to do this using the OOTB UI config?

In the lack of the above, another possible approach being considered is using a Web Services Before Operation Rule to run before each API request. In order for this to be accomplished, the rule may need to reference a private key that resides on the virtual appliance it’s running on. Is this possible/allowed within rules? If so, is there a specific directory the private key cert needs to be placed in for the rule to be able to access it?

Is the certificates folder on the VA able to be referenced from within the rule?

Hey, I would suggest using this Before Operation rule, i have referenced the below url, with slight modifications.
URL: OAuth verification for JWT Payload - #7 by tyler_mairose
Now in case of you storing the Private Key/Cert to sign the Token, i would suggest using Webservices connector with custom authentication.

Flow will look something like this:

  1. Onboard Webservices and Auth should be custom authentication.
  2. Now as you set it to custom authentication you will have new input fields available to put some data in. Use those input fields to store your private key/ cert.
  3. In before Operation Rule, reference the field where you have store the private key and then sign the token and generate the JWT Signed Token.
  4. In Before Operation rule itself, generate the access_token using the JWT Signed token. I believe there will be a API endpoint to get the access token once you have the JWT Signed token.
  5. Store the token in you connector variables.
  6. Use the stored access_token in subsequent API calls.

P.S all the libraries used are already present in OOTB VA Configurations so you should be good to use them directly by just putting import statements.

Hope this helps.

@neeraj99 Thanks for your response on the query raised and for the steps to implement.

We did try implement this approach but facing issues with libraries been used in the before operation rule code.
Below is the error we have observed in the log file during rule execution.

**class":"java.lang.RuntimeException","exception_message":"Error executing before operation rule for endpoint 'Test Conn': BeanShell script error: bsh.EvalError: Sourced file: inline evaluation of: **
**``import org.bouncycastle.jce.provider.BouncyCastleProvider; import org.bouncycast . . . '' : Typed variable declaration : Class: MediaType not found in namespace : at Line: 79 : **
**in file: inline evaluation of: ``import org.bouncycastle.jce.provider.BouncyCastleProvider; import org.bouncycast . . . '' : MediaType \n BSF info: PoC Test Connection at line: 0 column: columnNo"}**

Could you please confirm that the below are defined in IdentityNow?

import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.util.io.pem.PemObject;
import org.bouncycastle.util.io.pem.PemReader;
import com.squareup.okhttp.MediaType;

Cheers,
Sudha

For anyone who may stumble upon this post, and since I can’t directly comment on the shared link, the referenced code uses " com.squareup" libraries which don’t seem to be supported anymore. Hence the line private static MediaType JSON= MediaType.parse("application/json; charset=utf-8"); throws an error.
That being said, given it’s just to build and fire HTTP requests, which is what the connector does anyway, I don’t believe they’d be needed anyway.

Thanks for your help on this @neeraj99. pending a bit more playing around, I believe this gives us a way forward with what we’re trying to achieve.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.