- v1.0.0-latest-prod
AdminRestrictions are used to exclusively restrict an entity, such as a user or a user’s restricted roles/permissions, to only the specific targets within each specified restriction type.
An entity with no (empty) restrictions is not restricted in any way.
However, if an entity has one or more restrictions, it is exclusively restricted to only the specific targets within each specified restriction type. For example, assume we have "entityX" with restrictions:
[
{
VENDOR: [vendorA, vendorB]
},
{
STORE: [storeA, storeB]
}
]"entityX" is exclusively restricted to vendors vendorA and vendorB, and stores storeA and storeB. It is not allowed to access storeC or vendorC, nor is it allowed to access targets of any other arbitrary restriction type.
"Flat permissions" is the term used for all permissions that come from directly assigned permissions, and any permissions inherited from assigned roles or their ancestors.
Similarly, "flat roles" is the term used for all roles that come from directly assigned roles, and those inherited from their parent roles.
If an entity has AdminRestrictions, then its flat permissions and flat roles are only granted in those restrictions (effectively becoming restricted permissions and restricted roles).
If the entity has no restrictions, then those permissions and roles are granted everywhere.
AdminRestrictedPermissions are effectively added to whatever flat permissions and restrictions an entity already inherits, and thus are a way to give additional access within certain restrictions.
For example, assume we have an entity "entityX" with restrictions on [vendorA, vendorC] with READ_PRODUCT "flat permission", and "restricted permission" of UPDATE_PRODUCT on [vendorC].
In this case, the entity effectively has READ_PRODUCT permission on both vendorA and vendorC, and UPDATE_PRODUCT permission on only vendorC.
AdminRestrictedRoles are similar to Restricted Permissions.
These are effectively added to whatever flat roles and restrictions an entity already inherits, and thus are a way to give additional access within certain restrictions.
For example, assume we have another entity "entityY" with restrictions on [vendorA, vendorB] with PARTIAL_ACCESS "flat role", and "restricted role" of FULL_ACCESS on [vendorB].
In this case, the entity effectively has all the permissions within the PARTIAL_ACCESS role on both vendorA and vendorB, and all the permissions within the FULL_ACCESS role on only vendorC.
grantAnyAuthorityAllowed FlagThe AdminUser has the grantAnyAuthorityAllowed flag to indicate whether the admin user can grant any authority.
If true, the user can grant any roles or permissions to any users without needing to have those permissions itself.
If false, it can only grant authorities that the user itself has, either permissions that are directly assigned or inherited from roles within the specified restrictions, or permissions within their own specified restrictions from restricted roles or restricted permissions.
Represents an admin user to be managed and to sign in to the Admin Client.
Admin users can have roles and permissions (represented by IDs in a JSON array), AdminRestrictions, AdminRestrictedRoles, and AdminRestrictedPermissions.
Represents the restriction of an entity. Restrictions are used to exclusively restrict entities to only the specific targets within each specified restriction type.
See Restrictions for more detailed explanation about this concept.
Represents a permission that should only be granted within a particular restriction.
This is essentially a permission bound to an AdminRestriction.
This is useful to give additional access to users only within certain restrictions.
See Restricted Permissions for more detailed explanation about this concept.
Represents a role that should only be granted within a particular restriction.
This is essentially a role bound to an AdminRestriction.
Any permissions inherited from the role, its parent role, and its ancestors, will all be granted to entities that have been assigned this role - but only within the specified AdminRestriction.
This is useful to give additional access to users only within certain restrictions, similar to AdminRestrictedPermission.
See Restricted Roles for more detailed explanation about this concept.
Admin User Service uses the following Common Data Features which create additional tables within the Admin User Service data schema.
Durable Messaging - Employs DefaultNotificationHandler for sending triggered admin user, role, and permission modification messages with durable retry.
Leverages BLC_NOTIFICATION_STATE table for message send acknowledgement.
Resource Locking - Employs ResourceLockRepository for message consumption idempotency checking.
Leverages BLC_RESOURCE_LOCK table.
Admin User Service has its own unique tenant and application trackable implementation. It does not use the Tenant Trackable and Application Trackable BLC Common Features, it instead has its own custom narrowing and validation logic.
The reason for the custom implementation is that Broadleaf supports a "global" concept where we can have global admin users, roles, and permissions that are not associated to any tenant. This concept allows Broadleaf to provide out-of-box defaults that various tenants can use, rather than having to re-define them for each tenant. For this reason, Admin User Service entities do not fit any trackable concepts very well, hence the custom implementation on the "tenant-trackable" and "application-trackable" concepts.
Note that these global entities are visible but not mutable by tenant-level entities, and that global entities can only refer to other global entities. This is to prevent unintentional changes on other tenants. For example, a global role cannot be assigned a tenant permission, because if another tenant was using that global role, it’d suddenly have a permission within a different tenant, which should not happen.