Core Components of RBAC

User: User can be defined as a human being. This can also include intelligent autonomous agents such as robots, computers, etc. But to keep it simple, a user in this RBAC model is considered as human being. Users are assigned to roles [7].

Role: Roles are the user groups or can be defined as a job or job title in an organization.

Permissions of the users are associated with roles. Roles describe the level of access of the user [7].

Permission: permission is consent or approval of access to one or more objects in the system.

Permissions hold the access control to perform any actions. Authorization, access right, and privilege are the terms of the other that represents a permission. Permission helps to perform some action in the system [7].

ActionType: Action type is the four different type of actions used to perform operations on the object. Those actions are Insert, read, write and execute operations [7].

Resource: Resource is also called as objects. The object can be defined as data. Every system in access control model protects its object. Hence, the access control system protects directories, files, ports, and devices with action type [7].

Figure 4. RBAC [7]

20 2.4.2 RBAC MetaModel

Figure 5. RBAC Meta Model, adapted from [12]

The above representation of the RBAC Meta model and its relation between the components are explained as follows [13].

Users the humans are often represented as a user, but sometimes the user can also be systems and it extends to networks or intelligent autonomous agents.Roles are the job functions defined for an organization. Sometimes it also refers to the responsibilities of the particular role in an organization. Permissions are the organizational consent to perform specific operations. Action type is the elements used to classify permissions. Here every Action Type represents a class of security-relevant operations. Resource type defines all action types available for a particular meta-model type. Resource set represents a user defined a set of meta-model elements used to define permissions and authorization constraints. Protected resources are expressed using the standard UML elements called model elements. Authorization constraint expresses a precondition as a part of the access control policy. It imposed to every call to an operation of a resource. This precondition usually depends on the dynamic state, the current call, or the environment. The authorization constraint is attached either directly or via permissions, to a particular model element representing a protected resource.

2.4.3 RBAC Example

It is possible to develop the RBAC model using security modeling language. In this section of RBAC example, Secure UML[14] [15] has been used to illustrate the principles of RBAC. The abstract syntax of Secure UML is shown in Figure 6. Secure UML has annotated UML based models with the necessary information for access control. This is based on RBAC with additional authorization constraints. SecureUML[14] [15] defines a vocabulary for roles, role permissions and user-role assignments. SecureUML is well suited for business analysis and different technologies. It is used here to cover access control aspects of RBAC. The semantics of Secure

21

UML is defined using informal transformation rules. A role in the access control model is transformed into a single element of type security-role or secuml.role. The user is transformed into security-user or secuml.user. Permission is transformed into security-permission or secuml.permission. The resource is transformed into security-resource or secuml.resource. To represent any actions we use security-actions or secuml.action in SecureUML model. These action includes Insert, Update, Select and Delete[12]

Figure 6 : Security Actions of SecureUML Model [12]

Let’s assume the system as Study Information System of the University of Tartu, which provides information about courses, study programs, allow students to register for courses, exams and apply for a scholarship at the University of Tartu. For this example, we consider the situation as the department coordinator needs all of his eligible Students to apply for the newly introduced scholarship by submitting required information through Study Information System of the University of Tartu. Let's say that there are three users Andrew, Mark, and John, who play different roles in the considered example. We also consider that a resource (i.e, ScholarshipApplication), which characterize name and academic results of the student to be secured. This restricts by changing the value of attributes into a state, by defining resource ScholarshipApplication for the role Coordinator and role Student.

Figure 7: RBAC Example

22

Association class CoordinatorPermission characterises two actions for Coordinator: (i) action enterRegistrationDetails (of the type Insert) defines that Coordinator can enter information by executing operation setInfo() at class ScholarshipApplication, and (ii) action changeInfo(of the

type Update) allows to change the information of the ScholarshipApplication by executing operation changeInfo(). We also define authorization constraints to strengthen permissions.

AC#1:

Context ScholarshipApplication :: setDateTime ( ) : void pre : self . responsibleCoordinator . assignedUser ->

exists ( i | i . assignedUser = ‘ Andrew ’ )

Authorisation constraint AC#1 means that operation setInfo() can be executed by user Andrew, assigned to a role Coordinator

AC#2:

Context ScholarshipApplication :: changeDateTime ( ) : void pre : self . responsibleCoordinator . assignedUser ->

exists ( i | i . assignedUser = ‘ Andrew ’ )

Authorisation constraint AC#2 defines the restriction for operation changeInfo(). Association class StudentPermission defines the restriction for role Student. It defines an action getScholarshipInfo() of type Read says that only Student can view info in the ScholarshipApplication. To enforce this permission as authorization constraint AC#3 is defined.

AC#3:

Context ScholarshipApplication :: viewDateTime ( ) : void pre : self . enrolledStudent ->

exists ( p1 | p1 . assignedUser = ‘ Mark ’ ) and self . enrolledStudent ->

exists ( p1 | p1 . assignedUser = ‘ John ’ ) and self . enrolledStudent -> size = 2

Authorisation constraint AC#3 defines that only users Mark and John of assigned role Student can execute an operation viewInfo(). In this example security actions like Update, Insert and Select data are defined. An action Delete is not used in this example.

23 2.5 Attribute Based Access Control

Attribute Based Access Control (ABAC) [16] provides access on the basis of attributes.

Normally access control is based on the user identity who requests to perform some operation on an object. This is done either directly or through user groups or assigned roles. This approach has been noted that it. It is been noted that it is burdensome to associate the request for the user, roles or groups. Because they are insufficient in matching with the real world policies. Hence when we look for a solution it can be carried out easily through the attributes of the object, attributes of the user, conditions of the environment that are recognized globally for the policies.

This concept is called ABAC. ABAC controls access to its objects by evaluating the rules against the attributes of subject and objects, the operations it deals with, and the environment it dealt with. With ABAC it is easy to implement both Discretionary Access Control (DAC) and Mandatory Access Control (MAC). ABAC has the possibility of allowing. It is called Discretionary Access Control (DAC) because the access control is based on the discretion of the owner. It is also called Mandatory Access Control (MAC) because the system authorizes which subjects can access the data objects. This model is based upon the security labels [16].

Figure 8: ABAC Basic Mechanism [16]

Attributes: An attribute is a function which takes user or subject as an entity. It is a building block to define access control rules and to describe access. Access is granted to users with the help of policies. These policies combine the attributes together. Attributes are evaluated against the policies and access to objects are granted based on the evaluation [16].

24

Subject: The subject is an entity that sends a request to perform an operation. Which is mostly referred to as humans. As they are the one who creates to perform some actions in the system. It can also be referred as the requestor. Sometimes a non-person entity (NPE) can also act as a subject. A non-entity person (NPE) is an autonomous service that performs its operation with authority. Generally, every operation performed by the computer is either done by a person (human) or NPE is called as the subject. Which requests access to an object [16].

Subject Attributes: These are the attributes associated with the subjects or concerning the person or actor being evaluated. Each subject is assigned with a finite set of subject attribute functions.

Subject attributes are created by the user and constrained with different policies for security architects. This can be explained as the value of the subject attributes can be inherited from its corresponding user [16].

Rules: Rules are the constraints. Based on the evaluation of functions it returns either true or false.

Constraints are configured through policy languages. One can apply a constraint during the creation of subject and object, and also during the modification of subject and object [16].

Enforce: After evaluating rule relationship ABAC enforce relationships between attributes and environmental conditions. During enforcement flexibility in secure sharing and protecting information of specific resources in ABAC is been maintained [16].

Object: An object is the resource of the system that needs to be protected, for which the access control mechanism is managed by ABAC. They can be created by a subject on behalf of its user [16].

Object Attributes: Object attributes can also be referred to as resource attributes, which are attributes of the target or object being affected. While creating an object, values for its attributes may be set by the user through the subject [16].

2.5.1

ABAC MetaModel

Figure 9: ABAC Metamodel

When the subject is requesting access to the object, subject attributes are compared with the access control policy along with environmental conditions. Then it ensures if the subject can access the requested object.

25

Subject: Subject or user class is characterized by its own attributes called as its identity. The subject class takes action on a resource. Each subject attribute defines the character of the subject.

Such attributes are name, organization, title, project, and so on. Here subject’s role is considered to be an attribute [20].

Subject attribute: It is defined as a characteristic of the subject it can be a computing device through which a subject is requesting access. Examples, where attributes of IT component are used in making access control decisions are a user's access to online banking account, is restricted to a pre-registered mobile device or an organization’s policy allow VPN access to employees from a device registered in its domain

Environmental Condition: Environmental condition class is the inputs derived from the external factors. This can also be ignored in access control policies. These describe the operational, situational and technical environment with its environmental attributes. Such as date and time [20].

Policy: Whenever the objects are created, its policy rule of what subject attribute can access the object will be derived at first. So when the subject is trying to access the particular object in the form of attributes derived from subject and object, subject attribute matches with the existing policies. When the match evaluates to true access is granted through access control policy class [20].

Object: Object or resource class is also characterized by its own attributes called as its identity.

Object class allows the access of subject when policy evaluates to true. An object attribute is often extracted from the metadata of the resource. For example, object attributes can be the title, subject, author, project, etc., [20].

Object attribute: It is defined as a characteristic of the object. Which can be a resource component a device, A device here is defined as a computing device through which the access request of the subject access the resource. Sufficient knowledge of the information assurance capabilities and security robustness of a computing platform, as well as the risk associated with the environment in which it resides, will be required to determine the security risk of allowing access from that computing platform to the specific resource requested.

2.5.2 ABAC Example

Let’s consider our Study Information System of the University of Tartu, which provides course related information to the student and the University staffs in which consider that it is implemented with ABAC. When SIS is live with ABAC implementation consider the following scenario as an example of ABAC implementation. This SIS system has students from a different department, they can be considered as Subject. Every Subject has its own attributes called subject attributes.

Likewise, objects in the SIS has object attributes and environmental condition attributes. Object attributes can be any objects which the student or staff can able to access, can be a subject information, exam information, personal data, academics data, academics result, class data, etc., Environmental attributes can be a date, time or any other external factors other than subject and object. Which acts as a constraint in accessing different resources.

In our considered example of ABAC implemented the system, the student as a Subject, who has Subject attributes as software engineering department, with active student status is trying to access

26

the Object of the list of students in his department, which also has an Object attribute as software engineering department. Environmental condition can be the ongoing current academic year.

So here the policy can be defined as follows with a subject attribute, object attribute and environmental conditions like a subject which is from software engineering department with active student status can only access the object with attribute software engineering department under the environmental condition as a current active academic year. Hence for those subjects whichever has the respective attributes as described in the policy can only access its assigned object.

If the subject has to access the list of students from a different department (different object) like computer science instead of software engineering, the same subject has to have its respective attribute as computer science department. Only then according to the newly assigned policy this object would be accessible. This can be clearly depicted in the below diagram in which terms are mentioned very general for a better understanding of this concept.

Figure 10: ABAC Example 2.6 Summary

In this chapter we discussed the important access control models in detail. From those models, we took three most important Risk-Adaptive Access Control, Role based access control, attribute based access control for further research. We also described its metamodels with corresponding examples. For those examples, we considered Study Information System from the University of Tartu. Hence this chapter leads to the further research in identifying the main building blocks of an access control model.

27

3 Comparison of Access Control Model

Aim of this section is the result of finding an answer to the below question Q: How do we define comparison criterias for an access control model?

This section defines comparison criterias based on the fact that it should be common in every accesss control model, at the same time, it has its own unique key concept which will be different or similar that other access control model. Based on that an access control model can be divided in to three main components Subject, Policy and Object. Subsections below will be brief about these three main components.

3.1 Comparison of Subject

In order to understand the subject context, will start with a question: “How to identify a component as a subject component?" for this question, first of all, will refresh the subject term, what a subject is. The subject is the one who initiates the flow of access control request. Whichever the component associated with the component requests for access is called as subject component and all the subject component comes under the subject boundary context.

After that the subject components are identified, now we need to know the answer to another question: How does a subject help to compare access control model? As you see from the access control models discussed, the subject is not the same in all aspects. The boundary of the subject and its behavior differs according to its access control model.

For instance, in RBAC, User and Role are together called as the subject. So, User is the one who requests for access, as the user is connected to the role, based upon the role the access is restricted with the help of permission. So, the subject boundary of RBAC ends at Role.

In ABAC, Subject and Subject attribute are called as Subject. Here when the subject requests access, its attributes are evaluated by the policy. The subject boundary of ABAC ends at subject attribute.

RAdAC's [4] subject boundary is little bigger than other access control model. As it has to calculate the risk, Situational factor and heuristic are included in the subject boundary. with subject and subject attribute. If it is usual access control model only subject and its attributes will be enough to be called as the subject. As it is RAdAC[4], due to the need of risk calculation it considers situational factor and Heuristic as the subject. Along with it, Access authority is also included in Subject boundary because access authority can override an access decision under the specific condition when there is a need to attest to a subject's need. Hence in RAdAC[4] Subject, Subject attribute, Situational factor, Heuristic and Access authority are included in the Subject context.

Coming back to the research question, it can be answered as from the above discussion it is clearly known that subject is not the same in various access control model. One can understand it by comparing the subject context boundary of various access control model(For example with RBAC, ABAC and RAdAC[4]). By comparing, it can be found that which of the subject component suits well and efficient for the environment we consider. Also if we need to add any other factor from other access control model that may seem useful in our subject context.

28

Figure 11: Subject Comparison 3.2 Comparison of Policy

Comparison of policy will start with a research question RQ:"How to identify a component as policy component?" The answer is simple, can be explained as follows. The policy is the condition or a rule that evaluates the access request. It restricts the access request of a subject, which is not authorized to access the object. If a component helps in filtering the access requests that seems to act as a condition or a rule. So this way it is easy to identify if it is a policy component. A policy also has the following attributes: A scope, mechanism, an action, and a triggering event or condition, the rule set of policies must be centrally defined. As the question for first research question is obtained. Now will find out, RQ: "How does the policy help to compare access control model?" for this analysis, let us start figuring out the policy and its behavior of three different access control model one by one. In RBAC access control requests are filtered out with the help of Permission. Policy component of RBAC has two entities Permission and Action. Whereas the permissions available to the role are the union of actions and operations. Action determines what to perform with the operation. So what the user can do is determined by this Action entity.

Whatever the action is allowed by the user to perform are listed as Security Action (Fig). This

Whatever the action is allowed by the user to perform are listed as Security Action (Fig). This

Im Dokument Comparison and Alignment of Access Control Models (Seite 19-0)