Gyong Ju - South Korea

NIST RBAC PHP API package 0.65 released

Posted: June 2, 2010 at 10:22 pm

I’m happy to release my first public version of the NIST RBAC PHP API library. I’ve blogged a number of posts on this subject and I hope that the software is of use to you. The package can be downloaded from code.google.com.

The package contains the library, the data model in the form of MySQL DDL instructions, installation documentation and PHPDoc API documentation. It comes with three applications: a management application, a demo application and a test framework. The demo application shows you how to integrate the library with your own application.

The code is not OOP, I already had one complaint about that so if you’re completely hung up on OOP being the only acceptable thing in your life you might want to pass on this one. Then again if you’re a bit more mature you might still want to take a look and see how much you can salvage for your own project, or decide to take the code and go OOP bezerk on it and improve after your own tastes :-)

The library doesn’t contain any output other than arrays or true/false in accordance with the NIST RBAC formal API description (in Z notation). The management application follows a simple MVC pattern with the controller just passing on requests to the model and the model only respond with arrays or true/false returns. The view is based on a simple XHTML template.

There’s still a bit of work to do with the session management part of the management application, some sessions tend to hang around and I need to clean up the library code a bit to address this problem. Nothing serious, just annoying (at least in my opinion).

I’ll do some additional posts in the coming day to clarify the code and its usage. Probably necessary as it is extremely flexible and can therefore be a bit hard to grasp at the start.

Posted in: Featured
2 comments

Comments

  • Andrew said:

    Thanks for sharing your API, it’s very helpful.

    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

    [Reply]

    postme Reply:
    July 30th, 2010 at 17:43

    Hi Andrew,

    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

    [Reply]

    July 28, 2010 at 11:26Reply

Leave a Comment