Hi,

I have to implement a data controlling based on user rights with llblgen (4.2). User with certain rights, can see/edit only a subset of some entities based on some fields in it.

I tried it with an implementation of IAuthorizer to control this behaviour.

But this approach (#1) does not work with this use cases:

• Entity A (Aggregate) have Sub-Entities (n-tier), loaded with additional prefetch paths The set of sub-entities should be limited by a field stored in the aggregat entity (Entity A). Prefetchpaths are not resolved at this time, when the entity is checked in CanLoadEntity.
• if I return false in CanSaveExistingEntity, SaveEntity returns always true? The only way to inform the user, that he can't save because of missing rights, seems to throw an exception in this method? Any ideas how to solve this or do you use any other working approaches?

Another approach (#2) is to override some dataaccessadapter methods:

• to reduce the set of data: append predicates to the queries for certain entities
• control access rights: throw exceptions on insert/save/delete methods if rights missing

Advantages:

• better performance, because data is reduced in sql

• works with sub entities Disadvantages:

• writing complex predicates for sub entities is an high source of errors

• Authorize features of llblgen are completely ignored
• overriding FetchEntity(Entity2 e) is painful and only possible with reflection, because the internal used overload with predicates is private (FetchEntityUsingFilter)
• if some method-overrides missing -> security breach

monkey.ldb wrote:

But this approach (#1) does not work with this use cases: Entity A (Aggregate) have Sub-Entities (n-tier), loaded with additional prefetch paths The set of sub-entities should be limited by a field stored in the aggregat entity (Entity A). Prefetchpaths are not resolved at this time, when the entity is checked in CanLoadEntity.

Do you mean that when on CanLoadEntity fired by a BEntity's fetch you can't access B.AEntity on that event handler? Could you please post an example of that?

monkey.ldb wrote:

if I return false in CanSaveExistingEntity, SaveEntity returns always true? The only way to inform the user, that he can't save because of missing rights, seems to throw an exception in this method?

That depends. Please see the following quote from the Docs->Authorization failures:

Docs wrote:

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.

monkey.ldb wrote:

Another approach (#2) is to override some dataaccessadapter methods: ... Disadvantages:

• writing complex predicates for sub entities is an high source of errors
• Authorize features of llblgen are completely ignored
• overriding FetchEntity(Entity2 e) is painful and only possible with reflection, because the internal used overload with predicates is private (FetchEntityUsingFilter)
• if some method-overrides missing -> security breach

I also think that this is very hard to maintain, specially if you have/want to inject the authorization predicates in all queries. And, for save routines, you will have to do something like triggers, or implementing authorization in business logic. It's easier an more natural to inject the authorization logic through authorizers and adjust them to what you want.