Hierarchy & Access Control

OpenHierarchy centers on the concept of extensibility. Every web application will have a root section in which subsections and modules can be added, configured, started, stopped and removed at runtime.

The sections and modules can be arranged in a "tree-like" hierarchy, thereby arranging the parts of the application to reflect organizational, role based or other types of hierarchies. Basically, modules will add functionality to the system and sections are a way of organizing them. As an analogy, sections can be viewed as folders in a file system, and modules can be viewed as the actual files.

Routing

Each section and module* is configured with an alias and the routing of requests mapps directly to the "path"-part of the request URI by the use of these aliases. The root section lacks alias and implies the web application context root. Only the "path"-part of the URI will be used for the routing of requests down the hierarchy. Consequently, the query part will be ignored in the routing process but can still be used by the individual modules for various purposes. The routing traverses the hierarchy from the root section down to a single forground module, dispatching any background and filter modules along the way. Any subsequent parts of the URI path are left to be used as arguments by the receiving module.

Access Control

Each level in the hierarchy can be configured with access restrictions based on user or user group memberships. Requests are authorized by the framwork core as a part of the routing process. Hence, all unauthorized requests made to a section or module will be handled uniformly  and data confidentiality will be enforced in a common way for all parts of the application.

The access control, is performed in a deny-allow fashion, meaning that any section in the hierarchy disallowing access will take precedence over subsequent sections allowing access. At each level however, any type of access will suffice even if several types are specified. For example, if section A allows access to any logged in user as well as to members of the administrator group, a user fulfilling either of these criterias will be authorized.

Furthermore, each module can make use of the access interface available in the framework API in order to provide a lower level of access control for various parts of its information. Authorization for accessing  such information is implemented by each module.

*) Forground modules are dispatched on their alias, whereas background and filter modules can be triggered on aliases of various paths in the hierarchy, expressed with wildcards and regular expressions