19. ODRA Access Control

ODRA Access Control (AC) operates between interfaces and the system layer (Fig.19-1). AC controls all interfaces that provide a way to access to data. When a user with some role tries to access the data, he or she communicates with interfaces through methods from the application layer. The methods are client side commands. Executing one of them sends a request to the server. It receives it and then tries to communicate through the interface. Every interface makes a call to the AC method grantAccess(). AC checks if the user has proper privileges and if system layer commands can be executed. If the access is granted then system’s methods can obtain data from the database.

19-1. Access Control architecture in ODRA

19.1 The Main Idea of the Access Control Mechanism

Fig.19-2 shows the general schema of the Access Control mechanism. It starts to work when the user tries to login to the ODRA system. During the login process AC checks if the role putted by the user exists in the system. If a user account exists and the role exists then the user is logging to the system. From now on, he or she may execute some methods, for example, operations on views. Executing the methods causes setting up an access mode value in a UserContext object. This value informs later the AC mechanism what a kind of operation the user tries to do (creating, updating etc...). To make any operations on ODRA database objects, there must be a modeling database object on a DBView class object. This is the point where all calls to database’s objects must pass by. Because of that, this point in the ODRA’s architecture was the best place to put Access Control method for checking accesses. Here is a call to an Access Control method, grantAccess(), which checks privileges for the current user role. The method gets an access mode value from the UserContext object and checks if there is a permission for that kind of operation for that role.

19-2. The ODRA's Access Control Mechanism

19.2 Roles and Logging

The Access Control in ODRA uses a schema of the Role-Based Access Control (RBAC). The model establishes some roles, for example, administrator, client, anybody, etc. Each role has an own set of privileges. The system supports adding new roles. The users are assigned with one or more roles. After a successful log on, the user takes all privileges from his/her role.

Modifying role’s privileges changes rights for all the users who use this role. Hence in this system there are no users with individual rights. Permissions are set for a role, which means for a group of concrete users. This feature is very important to take into consideration before modifying role’s privileges. In most cases the users are not allowed to change the rights. Only a group of administrators should have rights for modifying role’s privileges.

The Access Control in ODRA starts to operate at the beginning, after a successful user’s logon. The logging process requires from the user to put the user’s login, password and the user’s role. When the user puts all these values and sends a request to the system, the Access Control at first checks if the given role exists in the system and then if the given user is allowed to use a given role. Every user may have more than one role. If a role does not exist in the system, or if a given user is not allowed to use it, then the access control exception is thrown and the user will not be log on to the ODRA system. If the role exists in system and the user is allowed to use it then log in to ODRA system is granted. After successful login a user’s session file and a context file are created. The context file keeps information about the current user role. Also it keeps information about current kind of operation (access mode) making by user. It is used by AC Mechanism to determine if user with current role is allowed to do this kind of operation.

19.3 Working in ODRA

After successful logon to ODRA, the user can execute methods. Not all of them involve Access Control Mechanism to operate because the Access Control mechanism operates on low level executions. It means that it does not checks every method execution but only these which refer to the View Objects Type. For example, the Access Control mechanism will execute its checking methods when the user will try to create, update or delete some view. AC will check if the given role has permissions to do operations on this object.

When the user executes some method, for example createView(), in the user’s context file the system sets a kind of operation value. Currently it will set the access value on ‘create’. After that, the Access Control method grantAccess() is executed. It searches for the system value ‘roles’. By this value the system keeps information on all roles in the system and privileges for every role. The AC mechanism finds the role for which the access is being checked and searches for privileges. When ‘create’ operation is being executed then privileges regard only to kind of operation, not a concrete object. In the cases where the user executes methods like updateView(), deleteView(), the privileges will regard to concrete view objects which are passed as an argument to these methods.

19.4 Permissions

Permissions are rights to perform some kind of operations. Usually, permissions are set by administrators. In many systems, also in ODRA, there is an implicit deny rule during granting the access to users. That makes system more secure and ensures that the users can’t access any information more that they have been allowed.

In ODRA the permission consists of information about an object, a role, a mode of access and an access value which determine if access is granted or not. Information about an object tells if the permission is set for type of objects for example Views or if it is a concrete object. The role tells for which role the permission will be added.

The mode tells about the operation kind. In ODRA there are 4 modes: create, read, update and delete. A mode is connected to an access value. Together the mode determines if the access is allowed, when the access value is set to ‘allow’, or forbidden when the access value is set to ‘deny’.

Permission with the access value flag set to ‘deny’ should be treated as restriction. The use of this negative value guarantees that sensitive data won’t be read by an undesirable person.

Permissions can be added to the View Type in general or to some concrete object from View Type, which is more specific and AC will make decision on that. For example, assume that there is a “CarView” object in the ODRA database. The user who log on to the system with role “client”, tries to update that view. AC checks privileges for the role “client” and sees that this role is forbidden to update View Type objects. But also sees that the role client is allowed to update the object “CarView”. In this case, rights for updating “CarView” objects are more specific than rights for updating View Type objects. AC will make a decision to grant access for the operation and the user will be able to update view.

19.5 Implementation

19.5.1 Added Java classes

AccessControl
AccessControlException
RoleManager

19.5.2 Most important Java methods

In the class RoleManager:

registerSystemRole(String rolename) – registers a role with the name given as an argument in the system variable “sysroles”
hasSystemRole(String rolename) – checks if the role of a name given in the argument exists in the system variable “sysroles”
unregisterSystemRole(String rolename) – unregisters the role from the system (not yet implemented)

In class AccessControl:

grantPrivilegeToRole(String rolename, int objectType, OID objectID, int accessMode, int accessValue, int grantFlag) – creates and adds privileges and permissions to the role given as an argument and to the object or action.
grantAccess( int objKind, OID object, UserContext ctx) – determines if the user with the current role can access an object

19.5.3 How it works

The access control in ODRA is based on two classes: AccessControl and RoleManager. At first, users’ roles must be created by a method from the class RoleManager. By default, the administrator role is created in the database. Roles are kept in the system variable “sysroles”. Every role has an aggregate object privileges which stores privileges for objects and permissions for making operations on them. Those privileges and permissions are created and added by the method grantPrivilegeToRole from class AccessControl. At first, this method checks for existence of privilege for the object given as an argument. If the privilege doesn’t exist then it is created. If the privilege for given object already exist, then it is only updated to the current value from the argument. It means that creating and updating access value for the object is done by one method – grantPrivilegeToRole. So this method can be executed many times, with even the same arguments and doesn’t create duplicates of privileges.

The method takes as an argument:

grantPrivilegeToRole(string rolename, int objectType, OID objectID, int accessMode, int accessValue, int grantFlag)

rolename – the name of role for which privilege will be added.
objectType – the type of object for which access will be defined.
objectID – concrete existing object for which access will be defined or null. (If null then more general permission is created, just for CRUD actions).
accessMode – is type of operation on the object (create, read, update, delete).
accessValue – determine if access is given or forbidden (allow / deny).
grantFlat – determine if user can pass on privilege to other user (not yet implemented)

The second most important method in the class AccessControl is the method grantAccess. It is executed when there is a try to access the view objects from the database (in future maybe not only views).

At first, method searches for role for which is access checking and after that, checks privileges for that role. If privilege is found then access is given, if not, then an exception from the class AccessControlException is thrown.

The method takes as an argument:

grantAccess( int objKind, OID object, UserContext ctx)

objKind - the type of object for which access will be defined.
object - concrete existing object for which access will be checked or null. (If null then more general permission is checked, just for CRUD actions).
ctx – user context object, which keeps information about user role, and current action which will be executed.

If the object is null, then the method checks if a role has permission to do given kind of CRUD operation on given object kind. If object is not null, then access is determined on two ways. More detailed privilege takes higher priority. For example if role is forbidden for updating Views but there is privilege allowing updating given view (given object) then access for this operation is given.

References to the method grantAccess are kept in several places: in methods managing Views(create, update...) in the class ViewOrganizer and in the constructor of class DBView. Before references from the class ViewOrganizer there is a reference to the UserContext class object, in which there is setting up kind of operation which will be made.

Reference to the method grantAccess in the constructor of class DBView assure that every access to View objects from database will invoke the access control mechanism.

When the kind of operation is set up in a UserContext object, then the grantAccess method is executed and checks the existence of privilege for this action.

Users can log in with one role. During log on time, the method hasSystemRole from class RoleManger is executed. Method checks if the role exists in system. After successful log on, the user takes all privileges belonging to the role.

Last modified: August 14, 2008