Security
KMP's security is built on a RBAC (role based access control) model. Specifically a role is a collection of permissions and each role can be assigned to a member in multiple ways. When a specific call is made the members current permissions are checked and then access to that call is granted if they have the required member state and permissions.
erDiagram
member_roles {
int approver_id FK
datetime created
int created_by
datetime expires_on
int granting_id
varchar granting_model
int id PK
int member_id FK
datetime modified
int modified_by
int revoker_id
int role_id FK
datetime start_on
}
members {
longtext additional_info
date background_check_expires_on
int birth_month
int birth_year
int branch_id FK
varchar city
datetime created
int created_by
datetime deleted
varchar email_address UK
int failed_login_attempts
varchar first_name
int id PK
datetime last_failed_login
datetime last_login
varchar last_name
varchar membership_card_path
date membership_expires_on
varchar membership_number
varchar middle_name
varchar mobile_card_token
datetime modified
int modified_by
int parent_id
varchar password
varchar password_token
datetime password_token_expires_on
varchar phone_number
varchar sca_name
varchar state
varchar status
varchar street_address
int verified_by
datetime verified_date
varchar zip
}
permissions {
datetime created
int created_by
datetime deleted
int id PK
tinyint is_super_user
tinyint is_system
datetime modified
int modified_by
varchar name UK
tinyint require_active_background_check
tinyint require_active_membership
int require_min_age
tinyint requires_warrant
}
roles {
datetime created
int created_by
datetime deleted
int id PK
datetime modified
int modified_by
varchar name UK
}
roles_permissions {
timestamp created
int created_by
int id PK
int permission_id FK
int role_id FK
}
member_roles }o--|| members : "approver_id"
member_roles }o--|| members : "member_id"
member_roles }o--|| roles : "role_id"
roles_permissions }o--|| permissions : "permission_id"
roles_permissions }o--|| roles : "role_id"
Roles can be granted by:
- Direct Grant: Giving a member a role via the Roles admin screen
- Active Officer: When the Officers plugin is installed and an Office is configured to include a Role and a member is currently in that Office for a branch they will have that role (see Officers)
- Active Authorization: When the Activities plugin is installed and an authorization is configured to have a Role granted with the authorization then as long as the authorization is active the member will have that Role. (see Activities)
Permissions are what enable members to do things in the solution. Permissions also include qualifiers regarding the state a member is in which are checked before a member is able to execute a task that requires that permission.
A permission has the following fields:
- Name: Must be unique.
- Require Membership: Check will fail if the member does not have a current membership.
- Require Background Check: Check will fail if the member does not have a current background check.
- Minimum Age: Check will fail if the Month/Year of the member does not mean the member is older than the minimum age
- Is Super User: this flag will grant a member who qualifies the equivilent of passing all permission checks (again assuming they pass the membership, background and age requirements).
- Requires Warrant: This is a reporting feature to flag which permissions will require the crown to warrant the member.
- System: These permissions are directly tied to code in the solution. Their names can not be changed and they can not be deleted. However the qualifications for these permissions can be changed.
- Activities: If the Activities plugin is in use this is a list of activities that can be authorized by a permission. (see Activities)
- Roles: The list of Roles that the permission has been assigned to.
Roles are a collection of permissions that have been granted to a member.
Roles consist of:
- Name: must be unique
- List of Permissions: The permissions granted by the role
- List of members: The members who have the permissions and how they are granted.
- Active: The members who have the permission currently. If the permission is a direct grant (not through an authorization or office) it can be added or removed here
- Upcoming: Members who will have this role activated on a give date (this feature is mostly for incoming officers)
- Previous: A list of members who have had this role, when they had it, how it was granted, and a reason they no longer have it (if available).
If you are building a new plugin and please create an initseed that includes any system permissions your plugin will need. You can see an example at https://github.com/Ansteorra/KMP/blob/main/app/plugins/Activities/config/Seeds/InitActivitiesSeed.php
Also in your init migration please remember to delete your permissions in your "down" method.