Information Classification and Role Management

 In continuation of the previous post..

Approach for Implementation

 

Step 1: Assign Role Clearance Level (One-time activity)

o   Assign a single, high-level clearance to every role in the User Management screen and its purpose defines the highest sensitivity of data each role is permitted to access.

Role	Clearance Level
Admin	Secret
Finance Manager	Confidential
Lab Manager	Confidential
Lab Technician	Internal

 

Step 2: Classify Attributes (One-time activity via DACPAC)

o   Classify each attribute once, stored directly in the database via DACPAC seed scripts:

o   Attributes will appear labelled clearly with their classification levels within the Role Management UI.

Entity	Attribute Name	Classification
Account	Account Number	Secret
Account	Financial Data	Confidential
Instrument	Serial Number	Confidential
Contact	Email Address	Internal

 

Step 3: Automatic Permission (Minimal effort)

o   View Permissions:

ü  Default "View" permission granted automatically if the Role's assigned Clearance Level >= Attribute's Classification Level.

Role Clearance	Attribute Classification	Automatically Assigned View Permission
Secret	Secret, Confidential, Internal, Public	Yes
Confidential	Confidential, Internal, Public	Yes
Internal	Internal, Public	Yes

 

o   Edit Permissions:

ü  No automatic edit permission will be inherited based on clearance level.

ü  Explicitly assigned by administrators via the Role Management UI.

Note:

o   If a Role has Feature-level Edit permission, it implicitly has View permissions, and all attributes within that feature (entity) will automatically inherit Edit permission by default.

 

Step 4: Role Management (Overrides Only, Exception-based)

o   Role Management UI can override any permissions inherited by the system

·        Inherited permissions are clearly displayed by default (based on classification and role clearance).

·        Admins explicitly manage deviations only (typically minimal).

o   Planned Usability Enhancements:

·        "View All" and "Edit All" toggles for bulk actions.

  

Specific Use Case Examples

1. Use Case 1: Feature-level Edit Permission

• Granting Edit permission to a feature (entity) automatically grants View and Edit permissions to all attributes within that entity.

2. Use Case 2: Partial Edit Permissions (Attribute-level exceptions)

UI Form Behavior:

• Fields without Edit permission are read-only.
• On Save (POST/PUT), only authorized edited attributes are submitted.
• The backend explicitly validates submissions. Unauthorized edits trigger explicit authorization errors.
• Transactions succeed if no unauthorized attributes are submitted.

3. Use Case 3: Bulk Imports (CSF Import Scenario)

• A CSF import contains 4 samples; the user lacks edit permissions on 2 attributes.
• The import succeeds for samples that do not involve restricted attributes.
• The import explicitly fails or skips samples(which doesn’t have edit access to those attributes), providing clear feedback to the user:

"Some attributes weren't imported due to insufficient permissions."

4. Use Case 4: Masking Behaviour

• If a user has sufficient clearance but the View permission is disabled, the attribute appears masked in the UI (e.g., "****").
• If a user does not have sufficient clearance but the View permission is enabled, the attribute appears masked in the UI (e.g., "****").
• Both Clearance and View permissions are needed to view the attributes

Scenario	Outcome	UX benefit
Partial edit permissions	Non-editable fields disabled	Prevents confusion
No view permission	Attribute visible as masked (****)	Clearly indicates permission/clearance issue
No sufficient clearance	Attribute visible as masked (****)	Clearly indicates permission/clearance issue

 

Field Level Authorization and Data Classification

 Authorization architecture 

•   Implement Field-Level Role management allowing administrators to define View and Edit permissions for individual data fields based on user roles.

•  Incorporate Data Classification (e.g., Secret, Confidential, Internal, Public) for data fields and corresponding Clearance Levels for roles.

•  Implement Data Masking for sensitive fields when a user lacks sufficient permission or clearance to view the actual data.

UI Enhancements

1. Extend the Hierarchy Tree:

The main tree structure needs to be extended to include Fields as the lowest level under Entities.

• New Structure: Module -> Entity -> Field

The existing "Action" items (like Edit Account, Export Account) representing feature-level permissions should likely remain, grouped under Module.

2. Introduce Field-Level View/Edit Controls:

New Checkboxes: Add specific View and Edit checkboxes that only appear next to the Field-level items in the tree.

• These checkboxes control the permissions stored in the new RoleField Permission table.
• These could be new columns aligned similarly to the existing Read/Write, but clearly designated for fields.

3. Existing Read/Write Controls:

The existing Read and Write checkboxes should remain for the Module, Feature Group, and Action level items.

4. Add Classification Column:

Introduce a new read-only column in the tree/list view, aligned with the rows.

• For rows corresponding to Fields, this column should display the field's ClassificationLevel (e.g., 'Public', 'Internal', 'Confidential', 'Secret') fetched from the FieldClassification table.

5. Display Role Clearance:

Somewhere near the selected Role name (e.g., below the dropdown), display the MaxClearanceLevel assigned to that Role (read-only).

6. Implement Checkboxes for Fields:

Add aggregate View and Edit checkboxes at the Entity and Module levels within the tree.

This is to reflect and control the state of all underlying field permissions within that scope. Clicking them would allow bulk grant/revoke operations for fields

7. Add Search/Filtering:

Include a search input field above the tree to allow administrators to quickly filter the potentially long list fields by name.

8. Update Save/Copy Logic:

The Save button's action now needs to update potentially both the RolePermission (for feature-level changes) and RoleFieldPermission (for field-level changes) tables.

The Copy Privileges functionality needs to be updated to intelligently copy both sets of permissions if desired.

 

User Management

Role Clearance Levels: Each role is assigned a maximum sensitivity level it can access.

For instance, a Lab Technician role might have clearance = Internal (can see Class 3 and Class 4 data, but not Confidential or Secret), whereas a Lab Manager might have clearance = Confidential (Class 2) and an Admin clearance = Secret (Class 1).

We will represent this in the Role table (e.g. a column MaxSensitivity or numeric level). The Authorization service will interpret this such that:

• A user’s effective clearance is the highest of any role they possess.
• If a user has multiple roles, consider whichever role grants higher clearance prevails, since that user is trusted up to that level.

 Masking

Server-Side Masking Implementation: When a microservice determines that a field’s value should not be revealed, instead of dropping it, it replaces the value with a masked representation:

• Use a constant string or asterisks of matching length. E.g., Customer Name Peter Lynch might be sent as *********ch (preserving last 2 digits)

 Authorization Logic:

When a microservice is determining whether to show a field, it now must consider both the user’s explicit field permission and the Users Clearance level:

• Role-based check: Does the user’s role normally allow access to this field? (From the field-level permissions discussed above.)
• Classification check: Is the field’s sensitivity <= the user’s clearance level? If not, the field must be treated as disallowed, even if the role would otherwise permit it.

ER