It's kind of dangerous for templates to remove assertions since this could lead to unintended deletion of assertions resulting in outages. For example, you might have a user who has applied a template and then went ahead and added more assertions to that policy. If you apply an update, that will delete all those assertions that were not part of the template, we'll be deleting those assertions.

For this kind of scenario to work, the server needs to keep track of internally what assertions it created as part of the template (something that the user cannot change or set) and then it can delete those assertions only. It would be something similar to the resource ownership idea but not allow the user to set or change it and it has to be set the assertion level which we currently do not support.

We already have a separate delete assertion api - so we can easily update the authorization requirements for this api to have a unique authz check (e.g. similar to membership changes). So you can grant someone to have the capability to delete assertion but not update any. This would be pretty straightforward to introduce without breaking anyone.

As far multiple policy version - currently the templates do not have support for it. That seems somewhat advance use case for templates to start creating multiple policy versions.

@havetisyan Thank you for your response.

I have understood that due to the risks associated with deleting assertions via templates, there is currently no feature for assertion deletion through templates.

We already have a separate delete assertion api - so we can easily update the authorization requirements for this api to have a unique authz check (e.g. similar to membership changes). So you can grant someone to have the capability to delete assertion but not update any. This would be pretty straightforward to introduce without breaking anyone.

Thank you for your suggestion. However, there are some points I don't quite understand. I believe the API for deleting assertions is deleteAssertion(). Are you suggesting modifying this API to allow for a unique authorization check?

The reason I'm asking is that currently, deleteAssertion() requires policy update permissions, which means it allows not only deletion but also changes. I'm concerned that updating the current authorization requirements might affect existing users. I would appreciate it if you could provide more details.

One unfortunate limitation with the use of the RDL is that we're limited to a single authorization. At some point in the future we will move away from RDL but for now what we've been doing is that we're slowly moving the authorization from the RDL to the actual server code. So for example, if you look at the deleteMembership call, you'll see the RDL only shows an authentication call:

https://github.com/AthenZ/athenz/blob/master/core/zms/src/main/rdl/Role.rdli#L192-L208

There is only an authenticate call. And then if you look at the server code, then we carry out the actual authorization check in the server code itself:

https://github.com/AthenZ/athenz/blob/master/servers/zms/src/main/java/com/yahoo/athenz/zms/ZMSImpl.java#L5300

So when I say that we can extend the authorization for the deleteAssertion call, we won't replace it but rather we'll move it to the server and carry out two authorization checks:

("update", "{domainName}:policy.{policyName}");
("delete", "{domainName}:policy.{policyName}.assertion.{assertionId}");

So as long as one of those authorization checks passes, we're good to process the request. So you can add a policy and authorization some principal to have delete action on policy.{policyName}.assertion.* (for example) and they can delete any assertion in that policy and nothing else.

Thank you very much! I understand now. I will consider the PR!