According to docs, this is the normal procedure:
Inserting a new entity to the database. If this action is denied, the particular entity is simply ignored for persistence. If more entities are to be persisted, the object persister will move on to the next entity to save. Denying an insert action on an entity could lead to PK-FK sync issues if the PK side (e.g. Customer) is denied to be saved by the current user, however the FK side (e.g. Order) is allowed to be saved by the current user. If that's a possibility in your system, you should throw an ORMSecurityException instead of returning false from the (On)CanSaveNewEntity method if the action has to be denied.
Updating an entity in the database. If this action is denied on a single entity save (so no batch update), the save follows the same path as with Inserting a new entity to the database: the particular entity is simply ignored for persistence, and the object persister will move on to the next entity. If this action is denied on a batch update (UpdateMulti/UpdateEntitiesDirectly), the complete batch statement isn't executed.
So throwing an exception would make sense in the case invalidating one save action should invalidate others. If that's no the case you can simply return false. Now you want to know the reason or the involved entity, etc to show the info to the user. You can make those kind of things in your Authorizer. You could implement your own message logic to retrieve it later on your business or GUI. For example you could mantain an array of authorization errors in your authorizer, and create a property/method for such array, so after the save action you could inspect such property/method (just an idea).
