RBAC Data Structure

[KnightYoshi]

The docs state that, "Yii implements a General Hierarchical RBAC, following the NIST RBAC model." Does this include being NIST 2 compliant?

On to the data structure. I notice that there are four tables (not very semantically well named by default either).

I feel that the auth_item table is an all-purpose table for everything and then auth_item_child is an all purpose table for child nesting, I'm not even sure what the auth_rule table is for. I think it would be cleaner if a doubly linked list (Nested Set Model) over an Adjacency List Model. Roles and Permissions would be contained separately in their own tables and the hierarchy would be defined within those tables themselves.

This would also remove the overhead from the need to do joins to get the tree or leaf nodes. Then you would only need a table for Roles, Permissions, Roles/Permissions assigned to each other, and a table for assigning roles to users - since I don't know what the auth_rules table is for, I don't know if it would still be relevant.

The docs say "the table for storing rules.", but it's not clear what that means.

An article about doubly linked lists. http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

[samdark]

What are you referring as "NIST 2"? Would you please give a link?

I feel that the auth_item table is an all-purpose table for everything and then auth_item_child is an all purpose table for child nesting

Correct.

I'm not even sure what the auth_rule table is for.

Access rules data.

I think it would be cleaner if a doubly linked list (Nested Set Model) over an Adjacency List Model.

No. Why? Nested set requires rebuilding whole permissions tree on any modification. Also implementation of the nested set itself isn't trivial. See https://github.com/creocoder/yii2-nested-sets. I don't think it belongs to the core.

Roles and Permissions would be contained separately in their own tables and the hierarchy would be defined within those tables themselves.

There will be a need to additional table where we'll assign permission to role. Would complicate structure a lot for gaining nothing.

[KnightYoshi]

This article mentions NIST level 2 https://abiusx.com/archive/document/Fast%20&%20Flexible%20NIST%202%20RBAC%20with%20jRBAC.pdf

As well does PHP-RBAC http://phprbac.net/

I'll assume it is. (I can't say I know a whole lot on the subject, but having it up to current standards is what I'm asking about)

While I can see your point about needing to update everything to the right on the tree, that wouldn't be a regularly occurring situation in most cases I'd think. Also, I did mention there would be a permissions table, which would separate and clarify roles from permissions - it would remove the need to do joins though to get the tree structure. Since querying the tree would be more common than updating it, I would think that's were preference for better performance would be focused. Also a doubly linked list is easily portable.

Can you give an example of the access rule data and how/when it would be used. I'm not sure I understand.

[KnightYoshi]

Also, if you wouldn't mind replying to my thread; I posted in the Yii forums about the order of inheritance about the RBAC library.

[samdark]

Yes, Yii is implementation is current. Both roles and permissions are nested.

it would remove the need to do joins though to get the tree structure.

How? You'll still need to take roles nesting into account, check which roles is assigned to user and traverse permissions hierarchy for each role.

Also it's not clear what part of the tree is needed to get access decision each time so I doubt nested set would be of any help.

Can you give an example of the access rule data and how/when it would be used. I'm not sure I understand.

TimestampMoreThan rule. Data holds timestamp to compare to. Timestamp is editable via UI in admin panel.