...
re-strict's interface ISecurityContext can give you a list of access types that are valid for the context and the principal. An access type is a privilege, e.g. "edit".
Standard access types:
- create
- delete
- read
- write
- find
- search
- edit
In other words, an access type specifies what a user is allowed to do with an object.
...
The terms "stateless" and "stateful" are slightly misleading, because they have nothing to do with states. The best rationale to remember is:
- some access types make no sense for objects, only for classes
- states make no sense for classes, only for objects
Search vs. find
There is a difference between the search and the find access type. Find IS dependent on the state, however. If search is prohibited for the given user and object, the find setting is irrelevant and the user will not even be presented with a search option (i.e. search button). The search access type setting determines whether the user is even allowed to search. The find access type setting determines whether the user is shown a found item.
...
If you imagine the set of access types from an ACL as a row of bits. Each bit can be set (access granted) or not (access not granted). To find the effective set of access types for a given person, the bit rows are simply ORed (or UNIONed if you prefer set theory over boolean algebra.)
This view needs some refinement, because access cannot only be granted, it can be denied explicitly. So this row of bits is not really a row of tristates:
- access granted
- access not granted
- access denied.
This extra technology has big advantages for excluding specific people or groups from certain access rights. This is hard to duplicate with access granted/not granted-only options.
The algorithm for handling denieds is simple: access denieds are interpreted in extra rows of bits and also ORed. The resulting union of denieds is then "subtracted" (set-difference).
...
Since tenants can be hierarchical, there are parent tenants and child tenants. (In German: "Supermandant" vs. "Mandant".)
Security context
- the security context provides all information for identifying (describing) the access privileges (e.g. read, edit, ...) of a user
- again: re-motion's security is based on state, not on the object. In other words: the access rights to an object are defined by the context of use, not access rights stored in the objects themselves (as is the case in Microsoft Windows and Fabasoft Components). In those security models security hinges on the object itself. In re-motion, security hinges on who wants to use the object in what context:
- owner, tenant, group, user, work-flow participant
- state properties ("Zustandseigenschaften")
- whether the object is archived already or not
Contrast this with an object-based security model, where the object can be secret, confidential, for massive rotation, etc. In the current implementation, a state is just a set of enums.
Caches
- the client has a two-level cache. There is
- an application-global cache
- a cache for the transaction
The cache is flushed as soon as the revision of the security settings changes. The revision changes as soon as the admin commits ACL changes, e.g.
- organisational structure
- adds or removes users
Embedding re-strict
re-strict is a library (or, more precisely, an assembly).
...