Actor Domain
PROPOSAL
I think we need to grasp this issue now especially as we have certain requirements from Amadeus that will impact the decision.
We currently have many entities that can be SecurityPrincipal. These include Partner, PartnerChannel, Supplier, Agency (which is stored in Actor) and in theory Provider and Operator. DistributionChannels are also allowed to be SecurityPrincipal
SecurityPrincipalUsers and SecurityPrincipalHmac are attached to the SecurityPrincipal and grant access to the system
Permissions Rules and EntityConfig are variously related to the Principal or the entity - this is not consistent
SecurityPrincipals are organised into a hierarchy by virtue of parentId
Our current pattern creates these records in the respective tables and optionally creates a SecurityPrincipal that has the foreignId of the entity.
In terms of UX we include fields such as the Permissions Rules and Config on the screens for the given entity and the resolvers for each entityType use dataLoaders and updates to manage the data across both the relevant entity table and the SecurityPrincipal table.
There are implied relationships between Partner, PartnerChannel and DistributionChannel in various foreign keys but there are also implied relationships in the hierarchy of SecurityPrincipal. It is possible to imply by foreignKey that Partner A owns a particular PartnerChannel but then imply a different relationship in the hierarchy of the related SecurityPrincipals. This can get messy and will only get worse.
We have no UX for SecurityPrincipal
We have moved gradually over the past two years from a system that could be seen as single tenant (ie Holibob owns and manages everything) to a system that is multi-tenant and "self-serve" where administrators of Partners require the same tools as we do to manage a subset of the data. AccessControl is the latest incarnation of this approach.
At the heart of. multi-tenancy system is the hierarchy of who/what belongs to what.
We have also recently built out a complex UX for managing Hierarchies and we use this for Curations and Site menus.
Rationalisation of this system requires that there is one table that determines the hierarchy of ownership and a single UX (Hierarchylist + DomainNavigator) that acts as the entry point for all administrators. A given administrator would begin their journey at the highest level node in this hierarchy that they belong to and be able to navigate to any lower level. On arrival at the a given node they would be able to edit the meta data of the given entity.
This is almost possible today. It is possible to build a hierarchical UX for SecurityPrincipal with a DomainNavigator for the SecurityPrincipal that has steps (forms) for each of the types (Partner, Channel etc)
There is however a conflict between the concepts of SecurityPrincipal and Actor.
It has always been intentional to keep the Security domain separate from the "Business" domain. There are several justification for this:
Separation of concern - in particular of security
Not every "actor" say Supplier, Provider etc requires to be part of security
Most organisations need some rudimentary common information such as name, address etc which does not sit well in the Security domain but would benefit from standardisation.
Security should deal with permissions, accessControl, authentication etc but not with meta data such as names, addresses and most likely NOT with the hierarchy of who owns what.
My proposal therefore appears simple.
ALL organisations (Partner, Supplier, Provider, Restaurant etc) are first created in the Actor table which is defined as a hierarchy by virtue of parentId. An Actor can have one or more roles in the system (ie it can be both a Supplier and Partner)
The UX is built around Actor and allows the the editing of meta data for each role that the actor has
Thus we can create say and Agency as a child of anything so it may be a child of a Partner or the child of another Agency
SecurityPrincipal remains as it is today and is perhaps just a role on an actor
The Hierarcy of ownership (ie the parentId) is migrated from SecurityPrincipal to Actor.
All other implied relationships from say Partner to PartnerChannel are removed as they are now apparent on the Actor tree
So EVERY Organisation is an actor and SOME Organisations participate in Security (ie they have users or HMAC that can authenticate)
Tables such as Partner will still exist but its name and address details will be in Actor. It will only store information that is unique to a partner.