Thank you for your feedback. The issue that you highlight is a bit of an implementation choice. The NIST RBAC standard only supplies guidance for handling permissions and determines that permissions are constructed out of objects and operations. The standard assumes you have already an existing system containing objects and operations. To quote the standard:

Permission is an approval to perform an operation on one or more RBAC protected objects. An operation is an executable image of a program, which upon invocation executes some function for the user. The types of operations and objects that RBAC controls are dependent on the type of system in which it will be implemented. For example, within a file system, operations might include read, write, and execute; within a database management system, operations might include insert, delete, append and update. The purpose of any access control mechanism is to protect system resources. However, in applying RBAC to a computer system, we speak of protected objects. Consistent with earlier models of access control an object is an entity that contains or receives information. For a system that implements RBAC, the objects can represent information containers (e.g., files, directories, in an operating system, and/or columns, rows, tables, and views within a database management system) or objects can represent exhaustible system resources, such as printers, disk space, and CPU cycles. The set of objects covered by RBAC includes all of the objects listed in the permissions that are assigned to roles.

And another quote from the standard that confirms what I wrote above:

Creation and Maintenance of Element Sets: The basic element sets in Core RBAC are USERS, ROLES, OPS and OBS. Of these element sets, OPS and OBS are considered predefined by the underlying information system for which RBAC is deployed. For example, a banking system may have predefined transactions (OPS) for savings deposit and others, and predefined data sets (OBS) such as savings files, address files, and other necessary data.

So in essence I had to make up my own. This is why I added the AddObject/DeleteObject and AddOperation/DeleteOperation to the non-standard function section of the API. They can be filled with anything you want to put in there, the example you’re giving in your comment is spot on, that’s exactly how you can do it. The current fill in the database are indeed controller functions, they are there as objects for the web based management interface. You can delete those if you do not wish to use the web based management interface. The same goes for the operations table, I’ve taken the standard CRUD set and every possible permutation but you can choose to change that to a completely different set or naming convention if you wish so.

Hope this clarifies my choices but I’m open to improvement suggestions.

Kind regards,

Meint

Thank you for your feedback, you had me worried a bit so I went back to check with the standard. This is what I found:

Each session is a mapping of one user to possibly many roles, i.e., a user establishes a session during which the user activates some subset of roles that he or she is assigned. Each session is associated with a single user and each user is associated with one or more sessions. The function session_roles gives us the roles activated by the session and the function user_sessions gives us the set of sessions that are associated with a user. The permissions available to the user are the permissions assigned to the roles that are activated across all the user’s sessions.

This excerpt is from page 7 of the “A Proposed Standard for Role-Based Access Control” document. After rereading this excerpt your argument certainly makes sense, there is no specific need for a many-to-many relationship but only a one-to-many relationship. I will change this in the database schema and associated code for the next version, probably will be in two weeks time.

Thanks for taking the time to let me know so I can improve the software.

Kind regards,

Meint

I was wondering one thing about the default data you have used, and a schema choice (I am just trying to improve my understanding of the RBAC implementation and NIST spec).

In your object table, you fill it with what look like controller methods/actions? Is this just for the initial RBAC management itself. For my implementation I was looking at having the object equivalent to one of my entities i.e. A Person. I then have operations as Edit/Create/View. Does this line up with your understanding of the spec?

Also I was wondering what the create, read, update and delete flags are for on the Operation schema. As I would have thought that create, read, update and delete are distinct operations in themselves?

Thanks

if I’m not completely wrong you have a little mistake in your concept. You introduced a mapping table for sessions to users (or vice versa). This is not neccessary, since the ANSI/NIST standard does not specify a many-to-many relationship between users and sessions. Any session in RBAC belongs to exactly one user. So instead of mapping the user to a session in a separate table, you can reference the user directly in the session table. Which means one JOIN less needed.

Cheers
Alex

happy to share and thank you for your kind words

Meint

I’ve released the code and will post about it this evening, hope it’s to your liking (although one guy from the first test group rejected the code out of hand because it wasn’t OOP).

Meint

Eagerly awaiting…

Phil.

I was looking for a way to localize my own phrases and found your post. Your idea perfectly fits my desires and quite simple. JSON files are easy to translate, even for people not familiar with programming. Thanks for telling us your idea

Thanks for posting this. Looking forward to using your library. Can you give an update on the status of your development?

Thanks in advance?