role settings to prevent assertion usage

[Michael Mueller]

Hi Team.

I am trying to define a role, which prevents a developer from using a specific assertion.

The initial idea was , just to exclude this specific assertion in the privileges.

It ends up, that I needed to "allow" all other assertions, as well, as to allow all other permission-types, having a role with 294 single permissions.

Additionally, if a new gateway version would introduce a new assertion or a new permission-type, I would need to edit this role again, to add the new components.

Is my understanding correct, that I can not "exclude" permissions, but only "include"?

Or do I miss anything?

Thanks

...Michael

[Michael Mueller]

As of : https://community.broadcom.com/discussion/evaluate-json-path-expression-assertion-v1-migration

The described way seems to be the only one, which is possible today.

Question answered.

[Joseph Fry]

I'm not sure of your motivations for disallowing the use of that assertion, but if its not a security risk or other danger to the environment, you might consider just detecting when it has been used and notifying the developer that use of the assertion is not allowed.  Perhaps even disabling the service and adding a comment to the top explaining why?  That has the added advantage of being able to explain why they cannot use that assertion, and what the alternative solution is.

[Michael Mueller]

Thanks Joseph.

The intend is to prevent something before it happens, not to fix it afterwards.

I would like to prevent the usage of a deprecated assertion when coding policies through Policy Manager.

Your suggestions are all valid, but I understand them as workarounds, like fixes after someone has used the deprecated assertion.

We are in consideration to migrate the deprecated assertion to a supported one. 

In principal, this could be a one-time activity, if we could prevent the usage.

If we can't prevent, we need to migrate several times, with all necessary efforts like regression tests, etc,.

Hope that describes my scenario.

Anyway, as we encountered performance impact, using a role with such a complex privileges setting, we now think about, to not prevent it technically, but organizationally. So, we are back at your suggestions ;)