re-strict dictionary and overview

Owned by reinhard reinhard (Unlicensed)
Last updated: Jan 22, 2010Version comment
7 min read

re-strict is re-motion's security module.

Group and group type

A group is an instance of a certain group type. Examples: A company might have several research groups code-named after famous Viennese Cafes: "The Sperl Group", "The Drechsler Group", "The Worthner Group", and so on.

Groups can be nested, so there are parent groups and child groups.

Consequently, in the Security Manager web application, the Group type form has a field Groups, which has a bidirectional relationship with the field Group Type in the Group form.

Position and group type

A position is a "slot" for a person in a group type. Certain group types include a set of positions, like "Head", "Assistant", "Spokesperson", etc.
If you mix the group type "research group" and the position "head" you get "head of research", for example. If every "Research Group" has its own cook, the position could be "Research Cook".

Note that a position can be shared by group types. The position "Head" might be shared by the group types "Department", "Committee", "Team", etc.

Consequently, the Position form in Security Manager has a field Available group types, which in turn has a bidirectional relationship with the field Positions in the group form.

Role

What happens when you instantiate an abstract entity like "Department"? You get a certain concrete group like "Univac Inc., Sales Department". This asks for a concrete user as its head, let's say "Alonzo Bosso". Another way to say this is: "Alonzo Bosso" has the role of a head at "Univac Inc., Sales Department". Role = a position in a certain concrete group.

Consequently, the User form in Security Manager has a field Roles for roles the given user can assume.

Abstract role

An abstract role (in contrast to a conventional re-strict role) can depend on the given object (e.g. "user in question is a work flow participant", in regard to the given object).
Abstract roles facilitate very fine-grained security concepts. Abstract roles are called "abstract" (detached), because in constant to conventional re-strict roles they are not a position in a group. "work flow participant" is a role automatically assumed by a user if he is invited to participate in the work-flow the given object is submitted to. There is no predefined group of "work-flow participants", however. This is the meaning of "abstract" here – the role is detached from any group.

You can specify generic privileges for an abstract role. Example: all users in project group 1 who are participants in the work-flow may delete the given object.

Abstract roles are defined by the application developer and compiled into the system.

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:

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

Stateless vs. stateful access types

Create and search are called "stateless" access types, because they can't be tied to an existing object. After all, the purpose of create is to make a concrete object in first place. The purpose of search is to unearth a concrete object in first place.

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.

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.

In an ACE you specify which group and which user has a certain collection of access types. Some of those specifications might be very specific, pointing to certain concrete users or certain concrete groups. Examples:

"John Doe has the access types edit and delete for all domain objects of class Invoice."

or

"The sales department under the stairs has access types read for all domain objects of class Invoice."
An ACL might contain vague specifications as well, like "Any department head has the access types edit and delete for all domain objects of class Invoice."

or

"Any research group has access types read for all domain objects of class Invoice."

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.

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

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.

An ACL's ACE entries are associated with one or more states (but handling of state combinations is not implemented yet). An ACL has to match a certain class. The ACL always matches the most specific class.

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.

Why is a tenant not a group? Answer: Because the separation of tenants is much more strict than the separation of groups within an organizational structure. It is not usually possible to have security models span multiple tenants – except when special abstract roles are created for this. "Reader from a different tenant is an example).

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

You can use it by linking it to your application:

In this picture, re-strict is part of your web application. For this use, re-strict is covered by the LGPL.

However, unlike other re-motion components, you can provide security via re-strict by implementing it as a web-service. Just connect re-strict and your app with a wire and a protocol:

In this picture, re-strict is part of a web service. A proxy provides the interface to re-strict and communicates with it over a protocol. Note that, at this time, no other provision is made for such a protocol than cleanly insulating the re-strict module with sensible interfaces.