The Core Principle of RBAC Architecture

While working on ERP systems, I used to think like this:

"This user can approve invoices."

It sounds normal.
It sounds practical.
But architecturally — it’s wrong.

When I slowed down and started understanding RBAC fundamentals properly, especially after reading the NIST RBAC Reference Model, I realized something important:

Power should never belong to a person.
Power must belong to a title.

That single shift changed how I look at access control design. To really internalize this, I rebuilt the idea using a Kingdom analogy. In my Kingdom model:

• 👤 Citizen → User
• 🎖 Title → Role
• ⚔ Power → Permission

A citizen is just a human.

Authority exists only because of the title they hold.

If someone is a Tax Collector, they can collect taxes.
If they lose that title, they lose that power.

The power was never theirs. It belonged to the title.

Giving Power Directly to a Citizen [Wrong way]

This is how many beginner systems are accidentally designed:

<?php

$citizen = [
    "name" => "Arjun",
    "powers" => ["collect_tax", "view_treasury"]
];

function can($citizen, $power) {
    return in_array($power, $citizen["powers"]);
}

if (can($citizen, "collect_tax")) {
    echo "Tax collected.";
}

At first glance, this works.But structurally, this breaks the core RBAC principle defined in the NIST model:

Permissions are assigned to roles.
Users are assigned to roles.

Not:

Permissions are assigned to users.

If we keep attaching powers directly to citizens:

• Power becomes scattered.
• Governance becomes difficult.
• Auditing becomes messy.
• Authority becomes personality-driven instead of structure-driven.

This is not a Kingdom. This is uncontrolled power distribution.

Power Lives Inside Titles [Right way]

Now let’s implement it properly — the way RBAC is meant to be structured. Instead of giving powers to citizens,we give them titles.

And titles contain powers.

<?php

$citizen = [
    "name" => "katappa",
    "titles" => ["royal_guard"]
];

$titles = [
    "tax_collector" => [
        "collect_tax",
        "view_treasury"
    ],
    "royal_guard" => [
        "protect_castle",
        "carry_weapon"
    ]
];

Notice the difference:

The citizen has no direct powers.

The title holds the powers.

This mirrors what I learned from studying the NIST RBAC structure:

User → Role → Permission

In my analogy:

Citizen → Title → Power

Checking Authority the Right Way

Now we don’t check: Citizen → Power

We check: Citizen → Titles → Powers

<?php

function can($citizen, $titles, $requiredPower) {
    foreach ($citizen["titles"] as $title) {
        if (in_array($requiredPower, $titles[$title] ?? [])) {
            return true;
        }
    }
    return false;
}

if (can($citizen, $titles, "royal_guard")) {
    echo "Jagte Raho";
}

Now power flows through structure. This is no longer a shortcut. This is modeled authority.

Why This Changes Everything

Imagine tomorrow the Kingdom decides:

Tax Collectors should no longer view the treasury.

In the wrong design, we would need to edit every citizen. In this design, we update only the title:

<?php

$titles["tax_collector"] = ["collect_tax"];

All citizens holding that title automatically follow the new law.That’s governance.That’s structured authority.And that’s the first fundamental lesson I learned from properly studying RBAC instead of just using it.