Mark's Code Fractal   

All security components have a base reference in the SysGrp table, which enforces unique names on the groups and roles within the cluster. Although the current focus is on embedded security support in the code base, the security services will eventually be split out to a security service publishing a public interface and implementing a protected interface internally, hiding the security and role tables from direct access by referencing schema definitions.

The SysInc and SysRoleInc tables define all include relationships for all levels of the system. The SysRoleEnable table defines all the enable relationships for all levels of the system. The ClusGrp/ClusRole and TentGrp/TentRole tables define the join between the SysGrp that defines the object and the specific cluster or tenant id in question. Then SysGrpMemb, ClusGrpMemb, TentGrpMemb, SysRoleMemb, ClusRoleMemb, and TentRoleMemb tables define the user membership in the groups and roles resulting.

Globals and lookups have security entries in the Sys(tem) triplet of Grp (Group) tables. All tables have a Sys(tem) entry, which acts to indicate Superuser status over that feature of a table across all clusters, tenants, and groups of data.

Cluster owned data has security entries in the Clus(Grp) triplet of tables. Having a permission group name in Clus when the data is owned by a Tenant indicates that the members have access over all Tenant data for the Cluster, but not for other Clusters.

Tenant owned data has security entries in the Tent(Grp) triplet of tables. Matching names in Clus indicate clusteradmin access to all the tenants in the cluster. Matching names in Sys indicate sysadmin access to all tenants in the system across all clusters in the system.

Joins will be allowed to go up to 7 GrpInc layers deep, or 8 group layers in total. More than that becomes too hard for most query optimizers to deal with. Only one of the three layers is probed at a time, starting with Ten[an]t if applicable, then Clus[ter], and finally Sys[tem].

There is a global "systemadmin" group and initial "systemadmin" account as it's initial member, each Cluster has a "[clusterdescription]clusteradmin" group with "systemadmin" as an included group, and each Tenant has a "[tenantname]tenantadmin" group that includes "systemadmin" and it's containing cluster's "[clusterdescription]clusteradmin]". Because the "systemadmin" group only exists in the Sys triplet of tables, it gets found last in the search.

Note that join-by-SecName is very common in the model. SecName will have a 64-bit signed integer for an id, generated by JPA automatically and explicitly generated by RAM storage models. The main reason for this approach is to avoid the introduction of typos in the security specifications; you can't select a name that doesn't exist without explicitly adding it and knowing that you are doing so.

The 2.13 model already had "System", "Cluster", and "Tenant" SecScope values. The "SystemGroup", "ClusterGroup", and "TenantGroup" scopes have been added 2026-03-19, which will be implemented by applying the usual table level security checks, but also ensuring that the user doing the access is a member of the appropriate groupnameid in order to access individual records of the table. Only one table in a given hierarchy of tables can specify one of the *Group values, with the nameid column added to that table searched according to the SecScope value in code, rather than by referencing the security group tables directly. That way the usual superuser type behaviour can be implemented for the *Group security as well. "SysRole", "ClusRole", and "TentRole" have also been added, as their name distinction is coordinated by SysGrp as well.

Loathe it though some may, administrators always can see a lot more than most users realize. If it isn't encryped, root sees it.