Some Context:

We have a requirement that requires our APIs to communicate with other systems, and they mandate us to provide a JWT client_assertion signed by a key-pair provided to us during onboarding and also for mTLS by another key-pair also provided to us. Now we want to communicate with these systems dynamically!

When signing by different private keys dynamically, I am now using JWKs (Which could be provided in the request or loaded from a JS file in DataPower's local directory, but most importantly we will not update the published API!) when signing the payload instead of static "Sign Crypto Object". So now the signing is done dynamically!

The Issue here is the dynamic behavior of the TLS Client Profile created and used in the "invoke" policy. Is there a way to have a dynamic solution to use a specific TLS profile depending on the request?

I want to avoid having a switch with "invoke" policies having the required TLS client profile for every system! That requires us to update our API for every system added or removed!

So is there a way to support this behavior dynamically?

Edit: I found a solution using the urlopen module, so what are the differences between it and invoke policy? Are there any drawbacks I should be concerned with? Are there other alternatives?

Thanks in advance.

------------------------------
Mohamed Alkhaligy
------------------------------

Hi Mohamed,
You're correct that the invoke policy's TLS profile setting is a drop down that only allows selection of known TLS profiles.  It does not currently allow a variable setting such as $(myTLSProfile), but I believe that is a valid requirement and you should open a request for enhancement to be considered.  The difference between urlopen, whether it be the GatewayScript urlopen module's urlopen.open function, or the XSLT dp:url-open extension element, is that you're writing your own code to send a request to some target server versus using the native API Gateway invoke policy.  It's a little more effort than simply clicking check boxes or specifying other configuration, but you should be able to specify all of the options you need in your code.
Best Regards,
Steve

Thank you Steve

I already went with the urlopen solution, but I was wondering whether it would be possible to create a user-defined policy based on the invoke policy with added functionality?

If possible, can you provide good resources for creating such a policy, as I am not yet fully aware of how user-defined policies are created and used?

Hi Mohamed,
I believe the invoke policy, in the API assembly if you modified the source or in the UDP would fail validation on publish if a $(name) were encountered for the tls-profile property as not being a recognized profile name. There is a mechanism of disabling some of the validation so you might be able to get past the validation error although that would apply to all APIs published. If that works you'll need to decide if that is something you'd like do given it could allow some invalid configuration to be published.

Best Regards,
Steve