ABSTRACT

Access control systems within an enterprise system are used to control the actions, functions, applications, and operations of legitimate users within an organization and to protect the integrity of the information stored within the system. Role-based access control (RBAC) is a relatively new access control system that maps to organizational-specific structures in a way that reduces administrative costs and improves security. Although role-based security models have existed for 20 years, their application has until recently been limited. We try to give a comparison between RBAC and traditional access control models and try to evaluate the different industries where these models can be utilized. We try to evaluate the NIST RBAC model as a standard for implementing RBAC and show the implementation by developing an application which uses RBAC for authentication and authorization for the computer system to be accessed. This also involves a discussion for different variations of the Role Based Access Control models according to NIST.

INTRODUCTION

Access control is generally concerned with determining what users and groups of users can perform which operations on certain resources [10][1][11]. The fundamental problem is that each system and application for which access control is enforced has a proprietary method for creating and managing users, groups, and a system specific meaning of operations and objects. For many organizations, the number of systems can be in the hundreds or even thousands, the number of users can range from hundreds to the hundreds of thousands, and the number of resources that must be protected can easily exceed a million.

Organization’s large IT infrastructure is a mix of hugely complex and incompatible operating systems, applications and databases spread all over the world. The organizations these days have a huge number of employees which keep increasing or decreasing all the time according to the organization’s need. It also has a working interaction with contractors, business partners, and customers, all of whom require access to various parts of the infrastructure. Most of the companies rely on manual or semi-automated administration of users, controlling their access to privileges for various resources on a particular system. This will inevitably become very complex and completely unmanageable if the organization is huge and the number of users of the system is in thousands or more. Often, different systems will have their own set of access requirements with different sets of administrators who will have overlapping skill-sets, leading to poor use of resources. This creates an enormous administrative overhead e.g. If there is a single administrator who needs to update even 25% of thousands of users everyday, it will almost be impossible for the system admin to do so. Furthermore, if multiple administrators are acquired for this job it could cause conflicts so the system becomes almost impossible to handle and maintain. Also, it would cost much more than if you were to have a single administrator.

As the complexity of the organization’s IT infrastructure increases, the demand for access control administration across the enterprise outgrows the capacity of manual administration across the distributed systems. Increased administrative complexity can also result in increased errors that, in turn, can lead to increased security risks. It is best suited to use the access control models to restrict unauthorized access and avoid any security risks. Access Control Models have long been used in enterprise systems and ERP’s so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users [10]. Different access control models are suited for different business applications and industries depending upon the scale and complexity of the system being developed. This report will try to analyze the different types of access control models as discussed above, that may be suitable for a variety of businesses and industry applications, giving their features, benefits and classification.

This document will be covering many issues related to access control and various access control models. The critical analysis of each of the traditional access control model will be provided as well as the comparisons with each other identifying their advantages and drawbacks. The industry specific implementation of each of the model will also be discussed i.e. which model is suited for which kind of industry and what models should be selected depending on the scale of the system. Then the more recent access control model which is being widely utilized nowadays will be discussed in more detail and its different versions will be evaluated. Also role-based access control will be discussed in different environments i.e. in a centralized application environment and also in a distributed application environment. In the end, there will be an implementation of the appropriate access control model for a particular industry application called BOS (Back Office System) that is a travel agency. This application will support the day to day business operations of the organization. The model used for this application will be Role-Based access control as the structure and requirements of the business will be supported using this RBAC. It does not require the ACLs of DAC and it does not need the high security of MAC because the access privileges can be interchangeable between the users of the system.

BACKGROUND

Access Control Models have long been used in enterprise systems and ERP’s so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users. The basic need of access control is to protect the system and its contents from intentional and unintentional damage, theft and unauthorised disclosure. The access control models that have been used in the recent decades are traditional access control models which are Access Control Lists (ACL’s), Discretionary Access Control (DAC) and Mandatory Access Control. Role Based Access Control (RBAC) is a more recent access control model which provides an alternative for the traditional access control models.

The most appropriate way to restrict access of resources from unauthorized users of the system is to use one of the traditional access control models as a means of implementing secure and reliable access for that system. There are many access control models present in this age of time which cater to different needs and provide different type of security depending on the nature, scale and type of the application as well as the industry for which the application is being implemented for.

Traditional access control models base access control on the discretion of the owner or administrator of the data. Under all traditional models, an end-user’s identity determines which access permissions are needed. This section gives a brief introduction to the predominant traditional access control models as well as some of the more recent models that have been utilized more recently. We discuss these models in more detail in the later sections:

• Access control lists (ACLs).
• Discretionary Access Control (DAC).
• Mandatory Access Control (MAC).
• Role-Based Access Control (RBAC).

Access Control Lists

ACL’s is one of the most common access control model being used for securing operating systems, applications, computer resources and networks. When ACL’s is selected as a model for implementing access control, each resource that needs to be secured has a list of users associated with them who are authorized to access the resource and even modify and make changes in it if they are allowed to. ACL’s as a model provides ease of access for the security administrator to see which users have access to which resource within the application or system. Also, modifying access to a piece of information is relatively simple; a security administrator can simply modify a user from the ACL list that is a user can be created, edited or even deleted easily.

There is a corresponding ACL present for every data or application, but it is not necessary to have a corresponding list that gives the network administrator information on all of the pieces of information to which a particular user has access. The only way for the security administrator to find out about any potential security violations on a particular data has to be checked by accessing each of the data individually. If the security administrator wants to revoke all the access privileges for a certain user, the administrator has to examine each list and then have to remove the user from each of the lists one by one.

Responsibilities for a user in an organisation may change, in this kind of scenario this model becomes more complicated and hard to manage. Instead of removing the user from every ACL, the network administrator has to determine which permission needs to be removed, modified or added somewhere according to the new position of the user in the organisation. In some situations the user can be grouped together in the list making it easier to change the ACL by just modifying the group information rather than each of the users individually. In some other cases elaborate rules can be applied to ACLs to restrict access to particular resource.

Discretionary Access Control Using Access Control Lists

Discretionary Access Control

The user who owns the data is the one who control access to that data in the discretionary access control model. ACL is a model which is derived from DAC. DAC is a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a user or process given discretionary access to information is capable of passing that information along to another subject [1].

Discretionary Access Control is used to stop the user from accessing the protected objects on the system. The user may also be restricted to a subset of the possible access types available for those protected objects. Access types are the operations which are performed on an object by a user, the operations include read, write and execute. Usually an object belongs to a user or a user is the owner of that object, this means that only the owner of the object has the authority to distribute and revoke access to that object. The owner of the object may give and retain access to the objects they control based on the rules of the DAC. The identity of users and objects is the fundamental basis for controlling access in a system within this model i.e. DAC specifies which users have access to which part of the information.

Mandatory Access Control

Mandatory Access Control is different from other access control models in a way that the security it provides is based on hierarchy and assigns each subject and object a specific security level (e.g., classified, secret, top secret etc.). The rules that govern the access to a particular for this model are:

No read up.

No write down or (own level write only).

Read down access gives users the ability to access any piece of information that is at or below their own security level. If a user has a secret security level, they are able to access secret and classified material but not top secret material. Write up access states that a subject’s clearance must be dominated by the security level of the data or information generated. For example, someone with a secret clearance can only write things that are secret or top secret. With these two access control principles, information can only flow across security levels or up security levels [1].

Mandatory Access Control

Role Based Access Control

In traditional access control models the approach for granting access to resources within a particular system or an application is to specify permission for each of the user within an organization. If the user is allowed to have access to multiple resources or information within a system, the user must be assigned permissions for each of the resource. This approach is tricky and not the most reliable way of implementing access control. When users join, leave or change responsibilities within an organization, each of the users who changes status within the organization that user’s access privileges information must be updated for each of the permissions. Achieving the above requires a lot of resources, time and also is prone to errors as an organization can have hundreds of thousands of employees and updating each of the users information one by one is not an efficient way. RBAC get rids of this problem because it takes advantage of the user’s role as the key to access rather than the user’s identification.

The basis for role-based model is the user-role and permission-role relationships. Each user in a role-based environment may be assigned to multiple roles, and each role may have multiple users as well. The roles that are assigned to a user depend on their job and responsibilities, and each role is assigned permissions according to role’s access privileges in the organization. Permissions determine the data and applications that may be accessed by which are also assigned to a role and that role is assigned to a user or multiple users. User’s role can be in many forms e.g. jobs like (bank teller, bank manager), geographic locations (London, Newcastle) or individuals (shift supervisor, managers). The advantage of using this model is that users keep changing with in the organization whereas on the other hand roles or job responsibilities for a particular role remain the same. Therefore rather than implementing the security on the user’s manually, roles are created which are assigned to users and any addition in a job specification is changed in the role description which in turn changes the all the user with that role.

RBAC is a technology that offers an alternative to traditional discretionary access control (DAC) and mandatory access control (MAC) policies. RBAC allows companies to specify and enforce security policies that map naturally to the organization’s structure. That is, the natural method for assigning access to information in a company is based on the individual’s need for the information, which is a function of his job, or role, within the organization. RBAC allows a security administrator to use the natural structure of the organization to implement and enforce security policy. This model decreases the cost of network administration while improving the enforcement of network security policies.

RBAC is designed to centrally manage privileges by providing layers of abstractions that are mapped one-to-many to real users and real operations and real resources. Managing permissions in terms of the abstractions reduces complexity and provides visualization and a context for implementing complex access control policies. Abstractions can be centrally managed resulting in real permissions on real systems.

Role-Based Access Control

Discretionary Access Control (DAC)

In a computer system, access controls restrict subjects (users and/or processes) to performing only those operations on objects (e.g., files) for which they are authorized. For each such operation, the access controls either allow or disallow that operation to be performed [3]. DAC model works on the basis that only the owner of a resource has the capability to authorize other users to have access to the same resource. This means that the users who do not have access to a particular resource and wants access to it, only the owner of that resource has the right to give access to them.

In Discretionary Access Controls (DACs), each object has an owner who exercises primary control over the object. ACL is one of the mechanisms which can be used to implement DAC and is one of the most widely used implementation for DAC. The access of information in DAC is based on the user’s identity and the rules that specify the user’s ability to have access to a certain protected resource or information. On the other hand ACLs are lists that specify user’s access privileges for the protected objects. DAC consists of set of rules which specify a user’s ability to access restricted resource or information. When a user wants access to a particular resource or information, the server searches the rule which specifies the user’s ability to have access to the particular resource which it wants access to. If the rule is found and there is a match for the user to have access than the user is allowed access to the resource, if there no match then the access for the resource to the user is denied. For example, there may be a rule which states that users from a certain group is not allowed to have access to a certain piece of information.

Discretionary access control (DAC model) works on the discretion of the identity of the user. In DAC access to any object (files, directories, devices, information etc.) is only allowed if the owner of that object is willing to give access. Therefore, the basis of this model is creator-controlled sharing of information and identity of the owner plays an important role in the working of this method. The owners of objects can specify at their own discretion in what ways they want to share their objects to other users i.e. which other users can have what level of access to the objects they own. This can be implemented in a fairly simple way by using access control matrix which contains the names of users on the rows and the names of objects on the columns giving information of which users has access to which corresponding object. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation [1].

ACCESS CONTROL MATRIX

The access control matrix is a combination of rows and columns with cells representing the permissions. In the matrix, the rows represent user/subjects and columns represent resources / objects. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation. For example, in a row-based representation an entry might read the equivalent of “KIM can access KIMSFILE and DONSFILE”. In a column-based representation, one might find the equivalent of “DONSFILE can be accessed by DON, JOE and KIM” [1]. The entries in the matrix describe what type of access each user has to each object. This representation of rows and columns is dependent on the model or mechanism being selected for Discretionary Access Control. The table below exhibits a good example of an Access Control Matrix.

ACCESS CONTROL MATRIX

The access control matrix such as the example above is a graphical view of a set of users and their access rights on particular set of protected objects. The access types mentioned in the table above are:

r denotes read access.

w denotes write access.

c denotes control permission access.

cp control passing ability.

CHARACTERISTICS OF DAC MECHANISMS

The complete implementation of DAC is based on the information which is stored in the form of an access control matrix. DACs are oldest and most widely used class of access controls, the access controls for both Windows and UNIX are DAC. The Unix DAC, for example, has the well known three primitive permissions read, write, and execute. When the initial implementation of DAC started, the five basic mechanisms that were used initially to represent information were:

• Capabilities
• Profiles
• Access Control Lists (ACLs)
• Protection Bits
• Passwords

The first two mechanisms that are capabilities and profiles represent the access control matrix information by row, connecting the accessible objects to the user. Whereas ACLs and protection bits represent the access control information by columns, connecting a list of users to an object. In the above five mechanism we will be mostly concentrating on the ACL model which is the most widely used model out of all of the mechanism present for DAC and also in this section a brief description of the other mechanisms will be provided [1].

Capabilities

In a capability-based mechanism for DAC, access to objects which have restriction on them being accessed such as files is granted if the user who wants access to it has the capability for that object. The capability is a protected identifier that both identifies the object and specifies the access rights to be allowed to the accessor who possesses the capability [1]. The basic properties of capabilities are:

The capability of one user can be passed onto another user.

The user who possesses capability may not alter or fabricate capabilities without the interference of TCB (Trusted Computing Base).

If a capability mechanism is used to implement DAC than the implementation should possess the facility to transfer capability from one user to other users. This ability of transferring capability from one user to another cannot be controlled and therefore capabilities has to be stored, determining all the users access for particular objects almost becomes impossible. Because of this reason implementing DAC using the capability mechanism becomes very difficult including the feature of revocation.

A pure capability system includes the ability for users to pass the capability to other users. Because this ability is not controlled and capabilities can be stored, determining all the users who have access for a particular object generally is not possible. This makes a complete DAC implementation, including revocation, very difficult. (Revocation may not be an issue, however, since a user who has access to an object can make a copy of the information in another object. Revoking the user’s access on the original object does not revoke access to the information contained in the user’s copy. After revocation, however, changes can be made to the original object without the knowledge of revoked users.)[1].

Profiles

This is another mechanism which can be used to implement DAC and have been used in some forms for several systems. When using Profiles [1] to implement DAC, a list of protected objects is used to associate each user to the particular object. The object names are inconsistent and they don’t agree on being grouped together, also their size and number are difficult to reduce. If a user has access to a large number of protected objects, the profile can also become very large and it is very complex to manage such a profile. In profile mechanism all protected object names should be unique to but in reality multiple objects can have multiple names, because of this reason full pathnames should be used to identify the objects uniquely.

One major drawback of this method is that when creating, modifying or deleting access to protected objects requires multiple operations because multiple users might have access to the same object therefore those user’s profile must be updated. Revoking access to an object in time for a user is very difficult unless the user’s profile is automatically checked each time that object is accessed. Also if some object is deleted, it will require some method to check whether that object exists in each of the user’s profile or not, which is also an extra overhead.

In general, with these two mechanisms i.e. Capabilities and Profiles it is very difficult to check whether which users have access to a particular protected object. This is a very important problem that needs to be addressed in secure system and there exists more feasible and more efficient mechanisms, the above two mentioned mechanisms are not the recommended implementations for DAC.

ACCESS CONTROL LISTS (ACLs)

Another approach to implement the DAC model for access control using the access matrix is by means of the access control lists (ACLs). When using ACLs, each object is related with an ACL, these ACL entries indicate the authorities a subject possesses which can be executed on that object. In the ACL mechanism the access control matrix is represented by columns.

By looking at an object’s ACL it is easy to determine which modes of access subjects are currently authorized for that object. In other words, ACLs provide for convenient access review with respect to an object. It is also easy to revoke all accesses to an object by replacing the existing ACL with an empty one. On the other hand determining all the accesses that a subject has is difficult in an ACL-based system. It is necessary to examine the ACL of every object in the system to do access review with respect to a subject. Similarly if all accesses of a subject need to be revoked all ACLs must be visited one by one. (In practice revocation of all accesses of a subject is often done by deleting the user account corresponding to that subject. This is acceptable if a user is leaving an organization. However, if a user is reassigned within the organization it would be more convenient to retain the account and change its privileges to reflect the changed assignment of the user.)

Several popular operating systems, such as UNIX and VMS, implement an abbreviated form of ACLs in which a small number, often only one or two, group names can occur in the ACL. Individual subject names are not allowed. With t

his approach the ACL has a small fixed size so it can be stored using a few bits associated with the file. At the other extreme there are a number of access control packages that allow complicated rules in ACLs to limit when an how the access can be invoked. These rules can be applied to individual users or to all users who match a pattern defined in terms of user names or other user attributes.

Access control is required to achieve secrecy integrity, or availability objectives. ACLs have been a popular approach for implementing the access matrix model in computer operating systems. Some systems approximate ACLs by limiting the granularity of the ACL entries to one or two user groups. Other systems allow considerable sophistication. ACLs have disadvantages for access review and revocation on a per-subject basis, but on a per-object basis they are very good. More flexible representation such as authorization tables provide for superior management of access rights, but are usually available only in database management systems. In a distributed system a combination of capabilities for coarse-grained control of access to servers, with ACLs or authorization tables for finer-grained controls within servers, is an attractive combination [10].

ACL MECHANISM WORKING

ACLs allow any particular user to be allowed or disallowed access to a particular protected object. They implement the access control matrix by representing the columns as lists of users attached to the protected objects. The lists do not have to be excessively long if groups and wild cards (see below) are used. The use of groups raises the possibility of conflicts between group and individual user. As an example, the ACL entries “PAYROL rw” and “Jones.PAYROL r” appear to conflict, but can be resolved in the design of the DAC mechanism. The Apollo system has a multiple, hierarchical group mechanism. The ACL entry has the form “user-id.group.organization .node.” As in Multics, if the ACL specifies access rights for the user by user-id then group access rights are ignored. This allows a particular user to be excluded or restricted in access rights [13]. In the Apollo, if a user is not on the ACL by user-id, but is a member of a group, those rights are used and organization and node memberships are not examined. Multiple group mechanisms add more complexity and may facilitate administrative control of a system, but do not affect the utility of a DAC mechanism.

Access to ACLs should be protected just as other objects are protected. The creation of groups m