Evaluate JSON Path Expression Assertion (V1) migration

[Michael Mueller]

Dear Team.

I hope this is not a duplicate post.

We recognized the announcement, that the Evaluate JSON Path Expression Assertion (V1) is flagged as deprecated in the release notes of Gateway version 11.1  here: Deprecated Features and Support (broadcom.com)

Additionally it is suggested to start using the "Evaluate JSON Path Expression Assertion (V2)" instead.

I am wondering about the best approach for:

• creating policies : Is there a possibility to prevent users from using the V1 assertion when editing new policies through the policy manager ?
• existing policies : What approach could be taken to migrate existing policies to use the new version V2?

Thank you and kind regards

...Michael

[Michael Mueller]

Just a gentle reminder.

I really would appreciate a comment on this ask.

Thanks

... Michael 

[Ben Urbanski]

Hello @Michael Mueller,

The only way to prevent a user from using the V1 assertion would be via RBAC. A role could be created that allowed all but that assertion. A user with that role would not see that assertion in the palette.

For migration of existing policies, I might suggest using Graphman with Policy as Code to identify all policies that use the V1 assertion. However, Policy as Code may not be ready for automatically switching the assertion to V2 (its initial scope was focused on a handful of assertions, and does not support the import of all assertions).

Knowing which policies have the V1 assertion, you could replace them with the V2 assertions using Policy Manager. In most cases, the configuration and behavior of both will be the same. However, you should regression test these policies after making the change to be sure.

Regards,

------------------------------
Ben Urbanski
Product Manager, API Gateway
Layer7 API Management
------------------------------

[Michael Mueller]

Hi @Ben Urbanski

RBAC based roles will help. Perfect advice !

I was already using the XML-code representation to identify policies and services to be migrated.

The current count of entities is 655. This number of affected code entities motivates us to look for different migration approaches, rather then doing it manually by Policy Manager.

I'd like o get a confirmation, if the XML-code representation of this assertion only differs in their surrounding XML - tag

Version 1 : EvaluateJsonPathExpression

Version 2 : EvaluateJsonPathExpressionV2

If so, we could do a simple string-replace exercise, and hence automate the migration.

In regards to the necessary regression tests. I would be interested in a kind of reverse dependency search.

Something like, find all services where a policy (e.g. policyFragment) is in use. A Referenced-by search ...

Any idea?

Thank you

Kind regards

...Michael

 

[Ben Urbanski]

Hello @Michael Mueller,

Yes, the XML representation of the v1 and v2 assertions is the same with the exception of the tag, and the fact that v2 can select a specific evaluator which would add an additional element not supported by v1. However, you should be able to convert from v1 to v2 by just changing the tag. And then, of course, do proper testing :)

Regarding reverse dependency searches, we have demonstrated something similar for specific entity types using Graphman and a script. We can share this example if you like.

------------------------------
Ben Urbanski
Product Manager, API Gateway
Layer7 API Management
------------------------------

[Michael Mueller]

Hi @Ben Urbanski.

That's exactly what I was looking for. Thanks a million for this confirmation !

Yes please, I would be very interested in the script/procedure you mentioned to do a kind of reverse-dependency search.

Thanks in advance.

...Michael

[Francois Lascelles]

Hi Michael,

Here's a tool to generate a report of reverse dependencies. The report is generated using a graphman query and a basic/extendable js. Those two things are packaged together in a postman collection but could be used outside postman in a different tool if you need. Created and tested against 10.1 cr4.

The output gives you a reverse-dependency report for encass and cwp. It lists all of them including ones that are used and unused, but could easily be tweaked to only show unused if you want to just focus on that. Please let me know if you have questions.

(this doc is copied from the attached collection collection)

Reverse Dependency Analyzer Sample

This Postman collection shows how to get a graphman summary from a L7 gateway and produce a reverse dependency analysis report for the following configuration entity types:

• cluster-wide properties
• encapsulated assertion configs

This has been designed for, and tested against gateway version 10.1 CR4

Out-of-scope:

• Reverse-dependencies for entities other than CWP and Encass configs.

Getting started

After importing the collection into your postman client, adjust the graphman target and credentials. Open the Analyze reverse dependencies "request" and substitute the default https://localhost:8443/graphman with the target of the gateway you want to analyze and select the Authorization tab and substitute the admin/7layer credentials to the admin credentials of the target gateway.

Understanding the output

This collection includes a graphman query with the relevant information to analyze. The resulting reverse-dependency report will render in the console output. The graphman response displayed in Postman itself does not contain the reverse dependency report but rather the graphman response including the forward dependency response. You can open the console using the shortcut Option-Command-C (on Mac).

In the output below, the report shows that the encapsulated assertion configuration "encasa" is used in the webApiServices rest1 and rest2, as well as the cluster wide property cwpa is also a dependency of the same two services.

Entities that don't have reverse-dependencies (that can safely be deleted) will show up in the report with an empty reverseDependencies property.

"reverseDependencies": {}

You can save this report from the console to a file in your workstation and search for an entity of interest to determine how it is included in services. You can also search {} to find all entities that are not included by any service (presumably to determine safe deletion).

Attachment(s)

Reverse Dependency Analyzer Sample.postman_collection (1)...postman_collection (1)   10 KB 1 version

[Michael Mueller]

Hi Francois.

Thank you very much for providing the collection and your comprehensive description.

I was hoping to get something which does a reverse dependency search for policyFragments to find services that are using these policies.

However, this example provides some great insides. 

While writing this response and looking into the details how this collection is working, I am recognizing, that it easily can be enhanced to fulfill my request as well, due to the generic nature of the GraphQL based graphman API.

I already start thinking about an additional graphman-client command, which would provide the same kind of functionality.

I am wondering a little about that the API query named "depencySummary". It is not referenced in any of the public available schemas. And even when asking graphman for its schema it is not included. So obviously somehow a hidden feature ?

This collection will definitively help and support me , in building what I am looking  for.

Thanks again.

Very much appreciated, as always :)

Kind regards

...Michael

[Francois Lascelles]

That's not part of the schema, it's just a name given to the top level query, you can pick any names you want in that syntax as long as children queries are part of the graphql.

[Michael Mueller]

Hi @Ben Urbanski.

One more question. 

You mentioned:

The only way to prevent a user from using the V1 assertion would be via RBAC. A role could be created that allowed all but that assertion. A user with that role would not see that assertion in the palette.

It might be obvious but it isn't for me.

How could I do a "all, but" constraint in the role permission rule set ?

The conditions available are "equal" and "startsWith". But I don't see a "not" or similar, so it seems I am not able to configure a "but".

The only idea I have so far, is to add  "all" privileges to all resource types separately, but for type "assertion", I exclude the V1 assertion. This would lead to huge number of privileges, which might have some impact to the gateway. 

Is there a smarter way in doing so ?

Thanks and Regards

...Michael

[Ben Urbanski]

Hello @Michael Mueller,

Currently, roles define what's allowed, and by exclusion what's not allowed. Therefore, this is the only way to do it today:

The only idea I have so far, is to add  "all" privileges to all resource types separately, but for type "assertion", I exclude the V1 assertion. This would lead to huge number of privileges, which might have some impact to the gateway. 

And I agree that this is difficult and perhaps not practical. We're considering better ways to allow administrators to control what assertions can be used as part of our new management UI initiative which is just beginning now.

Therefore, 

------------------------------
Ben Urbanski
Product Manager, API Gateway
Layer7 API Management
------------------------------

[Michael Mueller]

Thank you for clarification.

...Michael