Idea Details

Select a variable as private key (instead of the actual private key) on a routing or signing assert

Last activity 06-03-2019 08:33 PM
HeikoHudig's profile image
05-10-2016 04:35 AM

We use policy fragments for SSL and signing. We use these fragments in multiple policies and services that use different keys on one gateways. Currently, only the actual private key can be selected on a routing or signing assertion. We require the ability to select a variable that hold the name of the private key (instead of the actual private key). The value of this variable can then be set on service level. This would allow the same fragments for signing / SSL to be re-used for services with different private keys.


Comments

12-18-2018 10:03 AM

I need this in my life!

 

@Remco's solution is a workaround but can make policy management complicated. As he mentioned it would be better to solve the root cause and being able to put it in a variable.

09-28-2018 07:52 AM

I've had several customers with similar requests. They all run into limitation for policy migration requiring much more complicated solutions. For one customer the separation of duties is such that developers don't even have knowledge about (let alone access to) keys used in acceptance and production so this requires editing of policies at later stages by different teams.

02-15-2018 12:05 PM

I don't know that I would call it error prone, thats just a matter of writting it well, and the efficiency is a matter of milliseconds.  For me the issue is the maintenance headache that gets worse with the increased complexity, but at least it works for me today.

02-15-2018 08:55 AM

True, however we see this case where a big company has lots of departments (>20). Each department is its own legal and financial unit. An outbound service is configured to use a key and the receiver will monetize requests on the key being used. Also for multi-tenancy on intermediairs running gateways this could become very handy.

 

This said we can create a switch and program Routing assertions with each its own key. However this is not very efficient and also error prone. Behaviour for all these assertion should be the same except for the key. It would be better programming practice do write it once instead doing it for each instance. This also makes testing easier.

01-20-2017 05:12 PM

I don't see how this has any impact on whether or not you can turn your policy fragment into an encapsulated assertion; however, you could create an encapsulated assertion in which you switch which route assertion to use based on an input (the private key name) so that you can use the same encapsulated assertion in all of your policies and pass in the name of the private key you want to use at run time (i.e. the same service could use different keys by mapping a request parameter into the encapsulated assertion input).  You would want to handle the event of an input that did not map to any known key names.

That said, I do support the idea of route assertions accepting more settings a context variables.  (last I checked proxy host was supposed to accept a context variable and was broken).

06-03-2016 04:33 AM

05-10-2016 08:36 AM

This also helps policy fragments to be promoted to encapsulated assertions. If a private key is used, this is now impossible.