Permission in Blazam differ from Active Directory in one major (and extremely helpful) way.
| Feature | Active Directory | Blazam |
|---|---|---|
| Reusable ACL's | :fontawesome-regular-circle-xmark:{ .red } Each ACL is unique for each OU | :fontawesome-regular-circle-check:{ .green } Create one type of access and reuse that list for any number of OU's |
| ACL Naming | :fontawesome-regular-circle-xmark:{ .red } ACL's are simply a list of properties in the security tab with no real grouping or de-granularization | :fontawesome-regular-circle-check:{ .green } Named ACL's allow for quick identification of access and it's source as well as allowing the creation of role based ACL's |
| ACL inheritance | :fontawesome-regular-circle-check:{ .green } ACL's at higher level OU's propagate down except for overriding deny's | :fontawesome-regular-circle-check:{ .green } Blazam behaves the same as Active Directory in this regard |
!!! info "TLDR"
Blazam adds a layer of abstraction to Active Directory permissions. By including an `Access Level` layer between the OU permissions and the group assinged,
you can create a single ACL rule and reuse it for as many groups on as many OU's as you'd like.
The Access Level's you define can be reused or combined to create exactly the configuration you desire.
!!! example
A group `HR` could be given the `Access Level` `Read Users` (which allows only read access to usr demographics fields)
and the `Read Groups` `Access Level` to the OU's `Company/Marketing` and `Company/IT` while also receiving `Rename Users` for the `Company/Marketing` OU
as well as the `Deny Group Read` `Access Level` for the `Company/IT` OU.
This will result in a member of `HR` to be able to read user demographics in `Company/Marketing` and `Company/IT` while being able to read
the groups a user is a member of, only if the group is under the `Company/Marketing` OU.
They will also be able to rename users under `Company/Marketing`
!!! note
Permissions that are applied inherit fully down the OU tree unless a `Deny` permission is set at a lower level.
The core element of the permission system in Blazam is the Active Directory Group.
Any group added will allow the members of that group to log into the application.
Nested group members are counted.
Access Levels improve upon the default permission system found in Active Directory.
You can name your Access Levels however you'd like.
Permissions are split between different Active Directory object types. You can set different permissions for groups from users, computers, or OU's within the same OU, or any combination therein.
Under each object type allowed, you can choose which fields will be denied, readable, or editable.
Group membership control in Blazam is currently very rigid. A user needs three separate permissions provided.
The delegate user must be provided read access to the MemberOf field for users in order to see a user's groups, and MemberOf for groups to see groups members. (This requirement may be removed in a future version)
The delegate user must have Assign/Unassign action permissions provided to the parent group in order to assign users or groups to it.
The final permission that must be assigned to delegates is read access to users or groups to be able to add as a member of the parent group
Mapping permissions is similar to default Active Directory permissions, but utilizing the powereful Acces Level
component to ease and enhance the delegation process.
As a super admin, you will be able to impersonate the application experience of other users. This is extremely helpful when setting up permissions to verify the access you intended.