02-10-2012, 03:49 PM
Analyzing and Managing Role-Based Access Control Policies
[attachment=35046]
Introduction
Information technology pervades more and more our daily life. This applies to institutes that have different security requirements, such as hospitals, government agencies, and financial institutes. New technologies, however, go along with new risks, which must be systematically dealt with. Specifically, the information contained in the IT systems can be regarded as a key resource of an organization and must therefore be protected adequately. Due to the fact that insider attacks are a major threat for large organizations, it is mandatory to establish adequate mechanisms that enforce the access control requirements demanded by the rules and laws relevant to an organization.
For example, in Europe, strong privacy requirements such as those formulated in Directive exist. This directive, among other areas, applies to hospitals, and hence, specific organizational rules must be implemented in order to prevent privacy violations. A typical organizational rule in a hospital might be “a nurse can only see the records of all patients who have been on his or her ward within the previous 90 days.” Another rule might state that a physician can only delegate the permission to read a patient’s record to another physician who has at the same time activated a specialist role.
Module Description
Login
In Login Form module presents site visitors with a form with username and password fields. If the user enters a valid username/password combination they will be granted access to additional resources on website. Which additional resources they will have access to can be configured separately.
Create new User
In this module the administrator of the organization is to create the new user. The new user has unique id and some confidential information. This information shared only by the admin and the corresponding user.
Assigning Role
This module deals with the authorization and this assigned by the administrator. The authorization other wise called as roles. These roles are already defined and assign for user depending on their requirements. Only administrator has the rights to change the roles. The user does not change their roles. Based on the authorization the user jobs are differing.
Administrator
Administrator has full rights on the system. He/she can create new users and can assign the roles. Admin can view all the details on the system. He/she can update or delete data. Defining roles are also done by admin.
Job Processing
Particular user can do their job based on the role which is assigned by admin. User can see only his/her workspace.
Literature review
There are several works on the formal specification of authorization constraints Gligor formalize history via traces of states but end up with rather complex formulas explicitly talking about states. In contrast, first-order LTL allows for an elegant formulation of history-based SoD constraints.
Joshi define the GTRBAC model, which has the notions of temporal constraints and events. Joshi explicitly introduce points in time and duration in order to specify temporal contexts, whereas we currently concentrate on history-based and order-based SoD constraints. Clearly, we can extend our library of Isabelle theories in order to support GTRBAC and could introduce predicates for events. This is needed, for example, if we would like to deal with temporal delegation constraints such as duration constraints on delegation rules. In addition, Shafiq present a verification framework using Petri nets, which is based on GTRBAC. Similar to the validation approach with USE, the framework can detect conflicting and missing constraints. In contrast to the USE approach, the verification is tailored to GTRBAC’s event-based model. However, this verification approach can handle only finite sets of RBAC entities and has exponential time and space complexity. In contrast, we can prove general theorems on RBAC policies by means of theorem proving with Isabelle, regardless of whether the underlying sets are infinite or change at runtime. Often, the graph-based approach presented by Koch is mentioned in the context of policy verification. Among other aspects, this approach ensures that concrete RBAC configurations remain consistent with respect to a specified RBAC policy when administrative RBAC functions (represented as graph rules) are performed. In this respect, this approach is similar to our enforcement mechanism based upon USE. In fact, one could also build an authorization engine based upon a graph transformation engine. In addition, Koch et al. present an approach to the detection and resolution of conflicting constraint pairs, similar to the validation with USE. Currently, however, no tool support for the detection of conflicting constraints seems to exist.
Role-Based Environments
Separation of Duty is a security principle used to formulate multi-person control policies, requiring that two or more different people be responsible for the completion of a task or set of related tasks. The purpose of this principle is to discourage fraud by spreading the responsibility and authority for an action or task over multiple people, thereby raising the risk involved in committing a fraudulent act by requiring the involvement of more than one individual. A frequently used example is the process of creating and approving purchase orders. If a single person creates and approves purchase orders, it is easy and tempting for them to create and approve a phony order and pocket the money. If different people must create and approve orders,
then committing fraud requires a conspiracy of at least two, which raises the risk of disclosure and capture significantly.
Techniques and Algorithm Used
RBAC specification and validation approach based upon UML and OCL. UML is a general-purpose modeling language in which we can specify, visualize, and document the components of software systems. It captures decisions and understanding about systems that must be constructed. UML has become a standard modeling language in the field of software engineering. UML permits the description of static, functional, and dynamic models of software systems. In this project, we concentrate on the static UML models. A static model provides a structural view of information in a system. Classes are defined in terms of their attributes and relationships. The relationships include specifically associations between classes. The static UML model for RBAC consisting of the RBAC classes and associations is depicted (UML class diagram). A further diagram type relevant to our work is the object diagram. Here, objects are instances of classes, and links are instances of associations. An object diagram then provides a snapshot of a system at a particular point in time, showing objects, their attribute values, and links connecting the objects.
[attachment=35046]
Introduction
Information technology pervades more and more our daily life. This applies to institutes that have different security requirements, such as hospitals, government agencies, and financial institutes. New technologies, however, go along with new risks, which must be systematically dealt with. Specifically, the information contained in the IT systems can be regarded as a key resource of an organization and must therefore be protected adequately. Due to the fact that insider attacks are a major threat for large organizations, it is mandatory to establish adequate mechanisms that enforce the access control requirements demanded by the rules and laws relevant to an organization.
For example, in Europe, strong privacy requirements such as those formulated in Directive exist. This directive, among other areas, applies to hospitals, and hence, specific organizational rules must be implemented in order to prevent privacy violations. A typical organizational rule in a hospital might be “a nurse can only see the records of all patients who have been on his or her ward within the previous 90 days.” Another rule might state that a physician can only delegate the permission to read a patient’s record to another physician who has at the same time activated a specialist role.
Module Description
Login
In Login Form module presents site visitors with a form with username and password fields. If the user enters a valid username/password combination they will be granted access to additional resources on website. Which additional resources they will have access to can be configured separately.
Create new User
In this module the administrator of the organization is to create the new user. The new user has unique id and some confidential information. This information shared only by the admin and the corresponding user.
Assigning Role
This module deals with the authorization and this assigned by the administrator. The authorization other wise called as roles. These roles are already defined and assign for user depending on their requirements. Only administrator has the rights to change the roles. The user does not change their roles. Based on the authorization the user jobs are differing.
Administrator
Administrator has full rights on the system. He/she can create new users and can assign the roles. Admin can view all the details on the system. He/she can update or delete data. Defining roles are also done by admin.
Job Processing
Particular user can do their job based on the role which is assigned by admin. User can see only his/her workspace.
Literature review
There are several works on the formal specification of authorization constraints Gligor formalize history via traces of states but end up with rather complex formulas explicitly talking about states. In contrast, first-order LTL allows for an elegant formulation of history-based SoD constraints.
Joshi define the GTRBAC model, which has the notions of temporal constraints and events. Joshi explicitly introduce points in time and duration in order to specify temporal contexts, whereas we currently concentrate on history-based and order-based SoD constraints. Clearly, we can extend our library of Isabelle theories in order to support GTRBAC and could introduce predicates for events. This is needed, for example, if we would like to deal with temporal delegation constraints such as duration constraints on delegation rules. In addition, Shafiq present a verification framework using Petri nets, which is based on GTRBAC. Similar to the validation approach with USE, the framework can detect conflicting and missing constraints. In contrast to the USE approach, the verification is tailored to GTRBAC’s event-based model. However, this verification approach can handle only finite sets of RBAC entities and has exponential time and space complexity. In contrast, we can prove general theorems on RBAC policies by means of theorem proving with Isabelle, regardless of whether the underlying sets are infinite or change at runtime. Often, the graph-based approach presented by Koch is mentioned in the context of policy verification. Among other aspects, this approach ensures that concrete RBAC configurations remain consistent with respect to a specified RBAC policy when administrative RBAC functions (represented as graph rules) are performed. In this respect, this approach is similar to our enforcement mechanism based upon USE. In fact, one could also build an authorization engine based upon a graph transformation engine. In addition, Koch et al. present an approach to the detection and resolution of conflicting constraint pairs, similar to the validation with USE. Currently, however, no tool support for the detection of conflicting constraints seems to exist.
Role-Based Environments
Separation of Duty is a security principle used to formulate multi-person control policies, requiring that two or more different people be responsible for the completion of a task or set of related tasks. The purpose of this principle is to discourage fraud by spreading the responsibility and authority for an action or task over multiple people, thereby raising the risk involved in committing a fraudulent act by requiring the involvement of more than one individual. A frequently used example is the process of creating and approving purchase orders. If a single person creates and approves purchase orders, it is easy and tempting for them to create and approve a phony order and pocket the money. If different people must create and approve orders,
then committing fraud requires a conspiracy of at least two, which raises the risk of disclosure and capture significantly.
Techniques and Algorithm Used
RBAC specification and validation approach based upon UML and OCL. UML is a general-purpose modeling language in which we can specify, visualize, and document the components of software systems. It captures decisions and understanding about systems that must be constructed. UML has become a standard modeling language in the field of software engineering. UML permits the description of static, functional, and dynamic models of software systems. In this project, we concentrate on the static UML models. A static model provides a structural view of information in a system. Classes are defined in terms of their attributes and relationships. The relationships include specifically associations between classes. The static UML model for RBAC consisting of the RBAC classes and associations is depicted (UML class diagram). A further diagram type relevant to our work is the object diagram. Here, objects are instances of classes, and links are instances of associations. An object diagram then provides a snapshot of a system at a particular point in time, showing objects, their attribute values, and links connecting the objects.