Hi Boris,

You tagged OAS, therefore I assume you are using that product.

In OAS you have full control on your security model, you can adjust policies as per your requirements, and remove the one you don't want to have, granting it to a new role, let's say "DV Content Author with ML". And use inheritance to make sure that it does inherit the rest of the DV Content Author permissions and grants in case you need the equivalent of the out of the box role.

And then you just assign roles as needed.

This is what I meant with looking into the policies linked with DV Content Author.

In OAS you still have full access to the permission sets, and you could look into the resources and permissions linked to the application role via the permission set, and try to find something matching your needs (by name and guessing only: I did ask some years ago for the various policies resources to be documented, but Oracle said they didn't have such document internally and therefore there wasn't one that could be published).

Here is where Oracle said there wasn't a need to document the details of the permission sets…

The doc only cover the permission set itself: https://docs.oracle.com/en/middleware/bi/analytics-server/security-oas/grant-or-revoke-permissions-assignments.html

But, there are WLST commands that allow to work "inside" the permission sets.

On https://docs.oracle.com/en/middleware/fusion-middleware/platform-security/12.2.1.4/idmcr/security_wlst.html you can see that there are many commands available. A permission set is called "entitlement" in the WLST commands.

There is for example the command getEntitlement that let you display the resources and actions for a permission set.

If you execute getEntitlement(appStripe='obi', name='va.author') you get the output of the screenshot above coming from FMW EM.

Then there are commands like revokeResourceFromEntitlement or addResourceToEntitlement that allows you to remove or add a resource to a permission set.

Those commands could be used to remove the ML resource from the va.author permission set.

An alternative approach could be to use createEntitlement and create a permission set that replicates va.author but without the pieces you don't want, you can then grant the new permission set to the application role instead of va.author (meaning that you don't touch va.author, giving you more chances to be able to restore things if you broke everything by mistake).

I didn't test if it does work and what is the result. In my scripts I usually only list the resources for a permission set to compare across environments when doing migrations. I never had the need to remove or add a resource myself. But the commands are documented and should do the job.

(No need to say that you should only run this on an environment you can afford to lose, because when you are down there so deep things could go wrong…)