Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Another way to understand "abstract role" is to see it like an arbitrary tag stuck on a user temporarily.

User

A user is a person in an organisation. A user can assume multiple roles in an organisation. A user can also be a member of ONE owner group, but this is an administrative group, i.e. a group of administrators who may edit a user object in the Security Manager web application. The owner group is not really part of the organization, it exists purely for granting administrative privileges to certain users of the Security Manager web application in the organization. In other words: confusingly, owner groups and their users are very different from users as generally understood by re-strict. The former are administrators for the re-strict application; the latter are users of the actual application, i.e. the application re-strict protects.

Access type

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:

...

The application developer may define arbitrary access types. An example for an application-defined access type: the define role access type.

State

An object can have one of a set of states, like "being processed", "approved", "rejected", "archived", etc. Whether a certain access type (a privilege like "edit", introduced above) is granted or not can depend on this state.

...

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.

Access control lists (ACLs)

An access control list (ACL) is a list of access control entries (ACEs). An access control entry specifies which persons are endowed with which access types. You specify ACLs for a certain class of domain object PhoneNumber, for example.

...

Which access control types (organized in ACLs) are relevant for a given class constitutes the security metadata (or just "metadata") for that class.

"Adding" and "subtracting" access types

A given person might appear in more than one role. "John Doe", for example, might not only be head of the fire department, he might also be the assistant in the personell group. Each role might give him different access types.

...

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).

Matching ACLs

Not all classes have an ACL defined, but those that have also have a class definition. If a class has no ACL, then the ACL of the parent class applies. In other words, the security manager walks up the class hierarchy until it finds an ACL.

...

However, some access types are stateless, for example creation, searching, etc. (see above).

Tenant

A tenant is essentially an organizational customer of a software-as-a-service provider. A typical example is a municipality (Gemeinde Wien, Manhattan, City of London, etc.); more examples include the Fundamt, the Viennese lost property office, a customer of rubicon. It is possible to have a hierarchy of tenants.

...

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

...