Company authorizations
Company authorizations control the granting of permissions between companies. As a matter of principle, Lobster Data Platform / Orchestration restricts data access to the company account defined as the 'owner' of the data or the data object containing the data. A parent company of another company, according to hierarchy relations, does not automatically gain access to that company's data.
When setting up company hierarchies, it must be taken into account that this also applies to access to company accounts. In the Beispielszenario (see image), Smart Logistics AG first creates the sub-company SL Germany and is thereby automatically entered as the owner of the new company account. The owner may make changes to or delete the company account even without any permissions. However, the ownership of SL Germany does not entitle Smart Logistics AG to register SL Germany as the owner of another company (e.g. SL MUC). Even if Smart Logistics AG initially creates the new company SL MUC in its own name, it cannot transfer ownership of SL MUC to SL Germany without clearance to access its corporate accounts.
Authorizations from SL Germany to Smart Logistics AG may include different permissions for company accounts:
Create: For creating a new SL MUC directly with SL Germany as the owner, Smart Logistics AG requires authorization from SL Germany for the creation of company accounts.
Change: If the company SL MUC has already been created and is currently owned by Smart Logistics AG, ownership can be transferred to SL Germany if changing company accounts is allowed.
Read: The company SL Germany does not have to grant Smart Logistics AG permission to read its company accounts. Without read access, the company SL MUC becomes 'invisible' for Smart Logistics AG as soon as the ownership is transferred to SL Germany.
Delete: SL Germany can also allow Smart Logistics AG to delete company accounts in its possession by enabling authorization.
Authorization is always non-specific, so that all company accounts in the possession of SL Germany can be read, deleted or changed (or not). Whether a Smart Logistics AG user can actually use the granted permissions depends, of course, additionally on the basic activation of the corresponding permissions in the role selected or automatically assigned during login.
Controlled access to data objects shared within company hierarchies or even between companies without hierarchical relationships requires rules for the multiple relationships of the companies involved. Fortunately, Lobster Data Platform / Orchestration provides a number of clever mechanisms for defining company authorizations so that not all relationships between companies need to be explicitly and individually configured. Through the clever use of inheritance logic in conjunction with the structure of the company hierarchy, it is often possible to tailor the distribution of access rights in the overall system and still keep it manageable with a few generic and special permissions.
Specific procedures are presented in the Tutorial using sample scenarios.
The following section describes the user interface elements for configuring authorizations and explains typical configurations using some examples.
An overview of effective authorizations from the perspective of a specific company is provided by the Effective authorizations menu.
Setting up company authorizations
Overview of authorizations
The list of authorization (1) shows the company authorizations visible depending on context. The editor for Permissions (2) above is used to create new or edit existing company authorizations.
Authorizations editor
The options for issuing authorizations are relatively extensive. A desired result can often be achieved in very different ways.
The editor's operating elements are first discussed in the following section. Afterwards, the possible applications are presented using examples.
In the Permissions (2) tab, the permissions that will be released are specified.
'Company authorization' (1): Definition of the companies involved in the authorization.
The Company authorization (1) tab contains the elements that define between which company accounts or hierarchy structures permissions are to be authorized.
The elements on the left determine which companies are granted authorization for the permissions defined under (2).
As Permission granting company (3), exactly one company must be selected, which in simple cases is the only company from which authorizations originate.
Via specifications for Permission inheritance (4), the company selection can be extended to the subordinate hierarchy of the authorizing company.
The First level children setting refers only to the first sub-level.
The All children setting involves the entire subordinate hierarchy.
The Exclude permission granting company (5) option is set if no authorizations originate from the company at the top, or the entry point into a hierarchy defined by permission inheritance. This may be necessary, for example, to define a permission 'upwards', which is directed at the parent hierarchy level (7) (10). It also opens a simple way to target a specific group of companies (possibly with their subsidiaries) without the parent 'group' (see Companies as groups) granting permissions.
The elements on the right specify which companies are granted the authorization defined in (2). Two methods are offered for the 'recipient selection', which can also be used in combination. These methods are applied – as far as they are parameterized – to all 'granting' companies that are qualified according to the definitions on the left hand side:
The elements in the upper right area specify the recipients of the authorization relative to the granting company, whereby one or all levels below or above in the hierarchy can be addressed via Granting to hierarchy (7):
The First level children setting refers only to the first sub-level.
The All children setting involves the entire subordinate hierarchy.
The Parent setting refers only to the direct parent level, i.e. the companies that are specified as 'parent companies' in the company account of the granting company.
The Description (6) field can be used to describe the permission (optional). The recommendation for this describes the intended effects of authorization in order to be able to understand them more easily later.
The settings made in (3), (4) and (5) result in the set of authorizing companies.
The fields (7), (8), (9) and (10) define the company/companies to which the permissions set will be released. Here, the 'target companies' can again also be defined hierarchically. It is possible at the same time:
Grant authorization depending on the hierarchy relative to the authorizing companies (7+8)
Grant authorization to defined target companies (9) and their hierarchies (10)
►NOTE◄
The effect of authorizations entered here refers not only to the company granting the authorization, but to the entire host of granting companies!
The following options are available in the Granting to hierarchy selection list (7):
First level children – authorizations to all direct subsidiaries of the granting companies.
All children – authorizations to all subsidiaries (hierarchically descending) of the granting companies
Parent – authorizations to all direct parent companies of the granting companies.
Parents – authorizations to all parent companies (hierarchically ascending) of the granting companies. Limit to hierarchy (8) restricts ascending to all companies below the authorizing company, including the authorizing company, if (5) it is not selected.
As Granted companies (9), companies can be explicitly selected which will receive the authorization. In addition, the authorization can also be granted hierarchically here in the same way as in (7).
Authorized permissions
Under the Permissions tab, the rights that are to be authorized can be specified in detail.
If All (2) is selected under Mode (1), all rights are authorized. Under Custom (3), the permissions can be enabled or not by selecting and deselecting them in the permission tree (4).
Rights are divided into categories and groups. Selecting a category or group automatically selects all groups and permissions contained under it.
The search field (5) can be used to search specifically for permissions and categories/groups (6).
Examples
The following examples refer to this documentation's example scenario. Authorized permissions are not considered further in the examples, since only the authorization behaviour is demonstrated.
A green arrow A -> B means that company A releases to company B.
Example 1a – Explicit authorization
The company SL Germany (1) explicitly grants the set permissions to the company SL UK (2).
Example1b – Explicit authorization to multiple companies
The company SL Germany (1) grants the set permissions to SL UK (2) and Smart Logistics AG (3).
Example 2a – Hierarchical authorization
The company SL Germany (1) and its immediate child companies (2) authorize the company SL UK (3) to use the set permissions.
Example 2b – Recursive hierarchical authorizations
All companies (2+3) subordinate to Smart Logistics AG (1) authorize Smart Logistics AG (4) to use the set rights.
Example 3a – Granting authorization to company hierarchies
The company SL LDN (1) authorizes Smart Logistics AG (2) and its direct subsidiaries (3) to use the set permissions.
Example 3b – Authorization to relative hierarchies
All companies (2+3) subordinate to Smart Logistics AG (1) authorize all their parent companies (4) to use the set permissions. It is ensured that only companies that are hierarchically below Smart Logistics AG or Smart Logistics AG itself are authorized (5). Activating the setting (5) is recommended in most cases, since it can be the case that, for example, SL UK is subordinated to another company in addition to Smart Logistics AG, which is not a subsidiary of Smart Logistics AG and would then also be given authorization.
Example 4 – An analysis of effective authorizations
The carrier company (1) authorizes the companies SL UK (2) and SL Germany (4) to grant certain rights to shipments (3). In detail (see also rights) SL UK and SL Germany are allowed to use the 'carrier' company in a shipment (5) as a party (6).
