Permission Console Guide

This page provides a complete guide to using the Permission entity in the Namirasoft Access Console. It explains how Permissions work, how they define the smallest unit of access control, and how you can manage them to ensure precise security for your applications and services. Permissions are the building blocks of all higher-level access rules.

What Is a Permission?

A Permission is a fundamental access unit that defines a specific action a user or system is allowed to perform. Permissions do not exist in isolation. This is a component that is combined with Policies and Roles to build meaningful access structures.

Why Permissions Matter

Permissions matter because they provide the most granular level of access control. This is the layer where you decide the exact operations that are possible within your system. Without Permissions, roles and policies would be vague and overly broad, making it difficult to enforce strong security boundaries.

 

By defining Permissions clearly, you create a transparent system where users only receive access to the exact tasks they need. This reduces risk, prevents accidental misuse, and enforces the principle of least privilege.

How Namirasoft Access Uses Permissions

This is how access is structured in Namirasoft Access. Users first define Policies, which specify the actions a recipient is allowed to perform and the rules that govern them. Next, users create Roles, which group one or more Policies into consistent sets, making it easier to assign multiple rules at once.

 

This is how Permissions are created. To grant access, users enter the recipient’s email and select the relevant Policy or Policies, along with the Role or Roles that apply. By combining Policies and Roles within a Permission, users ensure that access is precise, transparent, and aligned with organizational security requirements.

 

This is how access is enforced. When a recipient attempts an action, Namirasoft Access checks the Permission against the assigned Policies and Roles. If the Permission includes the necessary Policies and Roles, the action is allowed. If not, the action is denied, ensuring secure and controlled access at every step.

Overview of Permission Fields and Options

This section describes each field visible when creating or managing a Permission in the console:

 

• ID (String): This is a unique identifier automatically assigned to each permission entry. It distinguishes one permission from another in the system.

• User ID (Namirasoft Account’s ID): This is the unique ID of the Namirasoft Account user who granted the Permission. It links the item to the sender’s account.

• Email (String): This is the email address of the person receiving the Permission. This email must belong to a registered Namirasoft Account. Without an existing account, you cannot grant the permission to that email owner.

• Policy (Enum): This is a predefined set of rules that specifies what actions a user can take within a specific Namirasoft product. This is used to create layered, flexible access controls by assigning one or more Policies to a single Permission.

• Role (Enum): This is a predefined set of user roles that defines specific access levels. This is used to group users into standard categories, such as administrator, developer, or viewer. This setup lets you quickly assign structured access rights while keeping permissions consistent across the application.

• From Email (String): This is the email address of the user granting access. It is used for identification and notifications.

• From First Name (String):This is the first name of the user granting the Permission. It helps identify the sender in a clear and human-readable way.

• From Last Name (String): This is the last name of the user granting the Permission. It complements the first name for precise identification.

• To User ID (Namirasoft Account’s ID): This is the unique ID of the Namirasoft Account user who received the Permission. It links the item to the recipient’s Namirasoft Account.

• To Email (string): This is the recipient’s email address. The system uses it to verify the account exists and to send a notification.

• To First Name (String): This is the first name of the user receiving the Permission. It ensures that recipients are easily identifiable when managing access.

• To Last Name (String): This is the last name of the user receiving the Permission. It provides clarity when reviewing granted Permissions and access assignments.

• Created At (DateTime): This is the date and time when the permission was initially granted. It is useful for tracking when access was given.

• Updated At (DateTime): This is the date and time when the permission was last modified. It tracks any changes to the permission.