Implementing an RBAC Engine

1. Implementing an RBAC Engine (100 Points).

 

For this assignment, you will implement an RBAC Engine as it was depicted in class. Your engine should be able to load a syntactically-correct RBAC policy, that is, it should be able to parse the policy from a text file, store the policy within some internal data structures, and been able to respond to an authorization request asking if a given user can be granted or denied a given permission. In addition, your engine should allow for modifying the loaded policy by adding or removing permissions, users and roles, and by changing the role-assignment (RA), permission-assignment (PA) and the role-hierarchy (RH) relations as discussed in class. 

 

You are free to implement your RBAC engine using the programming language of your choice. However, you are required to implement the command line interface we discuss next, so we can properly test your engine and we can correctly award you all the points you will deserve for your hard work. Please be advised that any deviations from the expected behavior of your code, e.g., it fails to compile or implement this command line interface correctly, will result in valuable points being deducted from your final assignment grade. 

 

Overall, the following commands must be supported: 

 

 

load-policy policy-file-name
 

Parses a text file identified by policy-file-name, containing an RBAC policy in the format shown in the class slides, and loads it into the internal data structures implemented by your engine. You should be able to load any policy that implements such a format, and you can expect all policies to be syntactically correct, that is, there is no need to implement an advanced parser that can detect and react to formatting issues within policy-file-name. If a given policy has syntax errors, you can just abort execution gracefully. In case the command succeeds or fails, no message must be shown to the screen. 

 

show-policy

 

Displays an already-loaded policy into the screen. For simplicity, you can use the same format as shown in class, or implement your own. If no policy has been loaded beforehand, no output will be produced by your engine. Since this is just an auxiliary command, there is no need for the format displayed by this command to match exactly the one contained in a text file containing the RBAC policy that was loaded beforehand. 

 

check-permissionuser-name permission-name
 

Checks if the permission identified by permission-name, can be granted to the user identified by user-name. If the permission can be granted, a message of the form: Permission Granted! should be outputted to the screen. Otherwise, the message Permission Denied! should be shown. Both messages should terminate with a carriage return (\n). No need to include any extra information in your response message. 

                         

add-user user-name
 

Adds a user identified by user-name to a previously-loaded policy. In case the command succeeds, or in case the command fails, e.g., no policy has been loaded, or user-name is already defined in the policy, no message must be shown to the screen. 

 

remove-user user-name

 

Removes a user identified by user-name to a previously-loaded policy. In case the command succeeds, or in case the command fails, e.g., no policy has been loaded, or user-name was not listed in the policy, no message must be shown to the screen. 

 

 

 

add-rolerole-name
 

Adds a role identified by role-name to a previously-loaded policy. In case the command succeeds, or in case the command fails, e.g., no policy has been loaded, or role-name is already defined in the policy, no message must be shown to the screen. 

 

remove-role role-name

 

Removes a role identified by role-name to a previously-loaded policy. In case the command succeeds, or in case the command fails, e.g., no policy has been loaded, or role-name was not defined in the policy, no message must be shown to the screen. 

 

add-permissionpermission-name
 

Adds a permission identified by permission-name to a previously-loaded policy. In case the command succeeds, or in case the command fails, e.g., no policy has been loaded, or permission-name is already defined in the policy, no message must be shown to the screen. 

 

remove-permission permission-name

 

Removes a permission identified by permission-name to a previously-loaded policy. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

add-permission-to-rolepermission-name role-name
 

Assigns the permission identified by permission-name to the role identified by role-name, thus modifying the PA relation consequently. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

remove-permission-from-role permission-name role-name

 

Removes the assignment of the permission identified by permission-name to the role identified by role-name, thus modifying the PA relation consequently. In case the command succeeds, or in case it fails, e.g., permission-name and role-name were not related, or one of the two is missing in the policy, no message must be shown to the screen. 

 

add-role-to-userrole-name user-name
 

Assigns the role identified by role-name to the user identified by user-name, thus modifying the RA relation consequently. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

remove-role-from-user role-name user-name

 

Removes the assignment of the role identified by role-name to the user identified by user-name, thus modifying the RA relation consequently. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

 

add-senior-rolesenior-role-name junior-role-name
 

Adds the role identified by senior-role-name as a senior role of the role identified by junior-role-name, thus modifying the RH as a consequence. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

 

remove-senior-rolesenior-role-name junior-role-name
 

Removes the role identified by senior-role-name as a senior role of the role identified by junior-role-name, thus modifying the RH as a consequence. As with all previous commands, the command should return quietly, that is, no message must be outputted to the screen if it succeeds or fails.

 

 

 

Sample Command Line Execution

 

The aforementioned commands will be executed in sequence, separated by a semicolon, producing a single output to the screen as a result of invoking the checkpermission command at the end. In the following example, a policy called ExampleASU.txt, similar to the one listed in the class slides, is first loaded, and a permission on a user called “Josie” is checked next. Once a response message is shown to the screen, your engine should terminate quietly. You are expected to parse the sequence of commands, separate each command, and execute it subsequently. Also, you should make sure your RBAC Engine can be called by the rbacmonitor name in the command line, by properly customizing the sample make file that will be provided in the class Blackboard site.

 

rbacmonitor “load-policy Example-ASU.txt; check-permission Josie p1” 

Permission DENIED!

 

In another example, the sample Example-ASU.txt policy is first loaded, a permission is added to the Student role, and then the same permission is checked for the user “Josie”. The result of executing the command differs from the previous example as a resulting of adding a new permission to the Student role. 

 

rbacmonitor “load-policy Example-ASU.txt; add-permission-to-

role p1 Student; check-permission Josie p1” Permission GRANTED!