There is a resource id that identifies the system. It is created when the authorization-ri component is first started and stored in property-manager. It is possible to retrieve the resource id of the system from the PermissionChecker OSGi service.
When the system resource is used, all permission checks return true (even if the target resource id does not exist).
Programmers, who develop custom permission check query extensions, should always take care of checking if the authorized resource id is the resource id of the system.
All three fields are part of the composite primary key of the table. The two resource ids are foreign keys that reference the resource table.
The child resource inherits all rights from the parent resource. Inheritance works transitively. E.g.: Multi-level role or user group hierarchy can be designed.
The two fields are part of the composite primary key of the table. Both fields are foreign keys that reference the resource table.
The component needs two caches to be able to work.
NoOp cache can be used, however, the tests show that with a no-operation cache the checkPermission function works at least twenty times slower.
With the simplest cache implementation (ConcurrentHashMap), and a simple three level permission inheritance graph, the permission checker can answer a 1.000 times in a millisecond on an average notebook. This might be worse a little bit with large set of data and with a real transactional cache. The cache size should be at least as big as many records are used frequently from the database frequently on one node.