Skip to content

Security

Jump to bottom
Josh edited this page Jun 27, 2024 · 14 revisions

Key Concepts

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 ||--o{ MemberRoles : has many
    MemberRoles ||--|{ Roles : belongs to
    Roles }|..|{ DELIVERY-ADDRESS : uses
    Permissions }|..|{ DELIVERY-ADDRESS : uses
Loading

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

image

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

image 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).

Developer notes

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.

Clone this wiki locally