Enhancement of Business IT Alignment by Including Responsibility Components in RBAC

Abstract

Good corporate governance requires an improvement of the definition and the enforcement of the employees‟ responsibility throughout the companies‟ processes. In the field of information technology, one translation of this requirement targets a strict alignment of the access control policy with the permissions needed by the employees to achieve the obligations linked to their responsibilities. There has been much work related to access control over three decades and Role Based Access Control (RBAC) has emerged as a reference model in that discipline. Although its advantages have been largely recognized, when taking into account the new governance constraints, it appears that its mechanism of assignment of users‟ permissions is improvable. In this paper, we propose enhancements of RBAC by taking into account the concept of responsibility and explain it can be modeled using the OWL Web Ontology Language.

Keywords

• Role
• Access Control
• Policy
• Responsibility
• Commitment
• Capability
• Accountability
• Separation of Duty

1 Introduction

IT governance frameworks [40,41] require companies to have employees‟ responsibility aligned with the IT constraints. This requirement concerns all layers, from the employees‟ responsibilities identified in the business processes up to their translation onto technical policies applied to IT applications and infrastructures. In previous work [ 1 ], we address that requirement with a responsibility model (figure 2) built around three sets of concepts: (i) accountability of the employee regarding an obligation derived from a responsibility; (ii) the rights required to fulfill the obligation; (iii) the commitment pledged by the employee to fulfill the obligation. Whereas the first two sets are common in the field of IT, the last one comes from social aspects that underline the importance of dealing with the engagement of the employee in the responsibility assignment process.

The review of the literature performed in [39] highlights that the specification of technical policies does not include the notion of responsibility as advised by governance requirements. In this paper, we propose an integration of our responsibility model with RBAC [ 2 ] to minimize the three weaknesses identified in section 4. RBAC is an access control model that simplifies structuring the access right for a domain. Policies are elaborated using a policy language such as XACML (Extensible Access Control Markup Language) [36]. The basic RBAC model can be extended by modeling using OWL (Web Ontology Language) [35] that enables going beyond the basic semantics of RDF schema to perform reasoning tasks necessary to enforce specific constraints such as the separation of duty (SoD) or role hierarchies. We also use OWL for the representation of our responsibility-RBAC model.

This paper is organized as follows. Section 2 introduces the RBAC model and its user to role and permission to role assignment process. Section 3 presents our responsibility model, section 4 integrates both models into a single one, section 5 compares the representation of our model with two representative existing works and the last section concludes.

2 Background: RBAC

2.1 The RBAC Model

The concept of role has been introduced in software engineering about 35 years ago and has followed the development of traditional access control techniques such as the Mandatory Access Control or Discretionary Access Control. Role Based Access Control (RBAC-Fig 1.) has been introduced in the NIST standard for role-based access control [ 2 ] and embodies the entire previously developed notions in a single model which is now the reference access control mechanism for most software applications. The publication of this standard has been followed by many related papers which adapt the model for specific fields (e.g. eCommerce, [ 3 ]), to propose alternative solutions according to other constraints (Context Aware RBAC, [ 4 ]), or for proposing solutions for managing some of its aspects (e.g. ARBAC [ 5 ], URA97 [ 6 ] or PRA97 [ 7 ].

RBAC is a high level model with the objective to simplify the management of granting permissions to users. This is especially necessary in multinational companies where the amount of employees often count in thousands. It provides access decisions based on two associations – the association of users to roles based on the function that users assume and based on their responsibilities, and the association of permissions to roles describing that a role has the permission to perform specific operations on objects. This means that it is easy to change the assignment of people to roles without changing permissions.

2.2 User-Role and Permission-Role Assignment

The process of assigns users to roles and permissions to roles is normally a managerial function performed by the business manager or the process owner to decide which employee needs to access what application to achieve her job. The actual implementation of this may be delegated by the application business owner to a security administrator. URA97 [ 6 ] and PRA97 [ 7 ] are both part of the ARBAC97 [ 5 ] model (Administrative RBAC) that permits the assignment of the users to roles and permission to role by means of administrative roles and permissions. Both URA97 and PRA97 are defined in the context of RBAC96 model family but are applicable for most of the RBAC model. Their philosophy is the creation of administrative roles managed by security officers. These administrative roles are granted administrative permissions to assign or remove user to/from roles. In the same way that RBAC96 defines role hierarchies, ARBAC97 defines administrative role hierarchy so that a senior security officer inherits permissions from a junior security officer below him in the role hierarchy. For example, if the junior has assigned an employee to a inappropriate business roles, the senior security officer can remove that employee from the role or change the permissions associated with it. URA97 gives a detailed explanation of the administration of the assignment process.

The simplest way for a manager to assign permission to a user is to assign that user in to a role that encompasses specific tasks to perform and has the required permissions to perform the tasks. By doing so, the manager implicitly obliges the user to accept the responsibility to perform the tasks but does not actually know whether the employee has agreed to this. Not taking into account the employee‟s commitment is an authoritarian way of managing staff and may result in company goals not being achieved due to unwillingness of employees to perform assigned tasks (see section 3.3). Although this may seems unavoidable, especially in large companies, it could easily be improved by incorporating acceptance of responsibility by a user within the role assignment process, as shown in this paper.

3 Responsibility model

In this section, we present our generic responsibility model as a proposed enhancement to RBAC. The complete responsibility model (figure 2) is presented in detail in [ 1 ]. The analysis of the concept of responsibility [ 1,10 ] highlights that there is a plethora of definitions for it. A commonly accepted definition of responsibility encompasses the idea of having the obligation to ensure that something happens. The responsibility model is built around three sets of concepts. The first set concerns accountability of the employee regarding the obligation targeted by the responsibility, the second set concerns the rights required to fulfilled the obligations and the third set concerns the commitment to be pledged by that employee.

3.1 Concept of obligation/accountability

We define an obligation as a duty to perform an action. Dobson et al. [ 11 ] classifies it following two perspectives: functional obligation as what a role must do with respect to a state of affairs (e.g. execute an activity) and a structural (managerial) obligation as what a role must do in order to fulfill a responsibility such as directing, supervising and monitoring.

Accountability and answerability are similar concepts that are composed of one or more obligation(s) to report the achievement, maintenance or avoidance of some given state [ 12 ] to an authority. For our model, we prefer the definition of answerability provided by Cholvy as an obligation or a moral duty to report or explain the action or someone else’s action to a given authority [ 10 ] and the definition of accountability from Laudon and Laudon [ 15 ] as a feature of systems and social institutions: It means that mechanisms are in place to determine who took responsibility of actions. Accountability thus includes answerability as well as the possibility of sanctions for non-fulfillment of obligations [ 13 ]. Stahl [ 14 ] argues that accountability describes the structures, required to facilitate responsibility and that responsibility is the ascription of an object to a subject rendering the subject answerable for the object. Stahl also focuses on the sanction as being of central importance for responsibility. He nuances the sanction as positive or negative.

3.2 Concept of right

We define the right as what is due to a employee. This concept is common but is not systematically embedded in the IT frameworks [ 16, 34 ]. It encompasses facilities required by an employee to fulfill his accountabilities. These facilities could include, amongst others, capabilities, authorities or the right to delegate.

Capability describes the possession of requisite qualities, skills or resources to perform an action [ 12,16,17 ] and relate to a user. This may be implied through access rights, authorizations or permissions [ 18,19 ].

Authority describes the power or right to give orders or makes decisions. This concept is introduced in CIMOSA [ 16 ] as the “power” to command and control other employees and to assign responsibilities.

Delegation is a right to transfer some part of the responsibility to another employee that pledges commitment for it (see section 3.3). This transfer may concern the transfer of right or of accountability or both. The delegation of an obligation may or may not be accompanied by the delegation of right for the delegatee to further delegate the same obligation [ 12 ].

3.3 Assignment/delegation process

We define assignment as the action of linking an employee to a responsibility and delegation is the transfer of an employee‟s responsibility assignment to another employee.

The commitment by an employee related to that assignment or delegation represents his moral obligation to fulfill the action and the assurance that he performs it with respect of an ethical code. The commitment remains a virtual concept, difficult to define as well as to integrate in a strictly formalized framework. In [ 20 ], Meyer and Allen acknowledge that commitment should be conceptualized as a psychological state concerned with how people feel about their organizational engagements. To bypass the integration difficulty, we propose to extend the model with the components that can be used to enforce the commitment.

Commitment’s antecedent in the literature relate to pragmatic variables [ 21 ] that may influence a person‟s commitment e.g. the age of the employee and the time he spent in the organization [ 23,24,25 ], the perception of job security [ 26 ], management culture and style [ 27 ], the employee‟s investments in time, money and effort [ 28 ] or how his experience is valued by the company [ 22 ]. A scientific survey of commitment also highlights that Commitment outcomes may really influence the quality and efficiency of the action achieved. Pfeffer in [ 29 ] explains that Employee commitment is argued to be critical to contemporary organizational success. The following list summarizes commitment outcomes: • Employee performance [ 30 ] – committed employees performed better when committed to both their organization and their profession. • Retention of the employee – many studies demonstrate the link between the commitment and the employee‟s turnover [ 28,30,31 ]. • Citizen behavior1 – research over these outcomes remain however inconclusive [ 32 ]. 1 According to [ 7 ] definition, it represents the individual behavior that is discretionary, not directly or explicitly recognized by the formal reward system, and in the aggregate promotes the efficient and effective functioning of the organization

Based upon the commitment outcomes and antecedent definition, we may assume that commitment for responsibility of an action means will increase trust in the achievement of an obligation or in the accountability attached to the responsibility, as well as increase efficiency (and consequently capabilities) for this employee to perform the action. 4

Mapping RBAC with the responsibility model

In this section we propose a novel model called responsibility-RBAC (figure 3). As seen in section 2, the three main elements of RBAC are User, Role and Permission (dashed boxes in figure 3) and the two main functions are User-role assignment (URA) and Permission-role assignment (PRA) indicated by dashed arrows in figure 3. Although RBAC presents many advantages such as facilities to grant or to remove permissions to a large number of employees, it also presents weaknesses regarding the following business IT alignment constraints: 1. Number of roles: the inflexibility of the model may result in more roles than users if all permission assignments are very distinct [ 33 ] or in order to accommodate a user specific constraint [38]. Moreover, in small organisation, the concept of role does not always map onto access rights. 2. Employee‟s commitment: RBAC does not offer cater for management of the employee‟s commitment regarding the tasks they are responsible for. 3. The representation of RBAC in OWL results in the following problems: inconsistencies in ontology [ 8 ], difficulty of detection of constraint violations using DL-reasoner [ 8 ], as well as the need to deploy complex architectures [ 9 ]

The three next sub-sections analyze the contribution of the responsibility-RBAC model to improve RBAC above listed weaknesses

4.1 Number of roles optimization

RBAC requires an employee (type of business USER) who needs a permission to achieve a task to be assigned to a role. Thus, if an employee needs to have permissions to perform a task which is independent of existing roles, then a specific role must be created or the task must be associated with an existing role, even if the latter is not directly related to the task. This is mainly due to the lack of granularity of RBAC that may lead to situations where the number of roles is larger than the number of users, or where roles do not reflect real job functions because they are assigned permissions for a too heterogeneous set of tasks.

Our proposal to solve those problems is to introduce the concept of responsibility as an intermediary concept between the user and the role in RBAC (figure 3). We consider that the role is a predefined set of responsibilities, that employees can be assigned specific responsibilities, independent of roles and that permissions are associated with the responsibilities for which they are required. This model allows us to refine the URA concept of RBAC: users are assigned to responsibilities as far as they commit to them. The responsibility is an abstract concept that could be either a concrete atomic responsibility or a concrete role (group of responsibilities). The PRA concept of RBAC is refined through associating permissions both to atomic responsibilities and to roles.

The tuple of concepts [user-role-responsibility] facilitates defining two types of user-role assignments and one type of responsibility-role assignment: 1. Direct role assignment: an employee is assigned to a role and gets the corresponding responsibilities and permissions. In that case, the role is often the main function of the employee and corresponds to his main function in the company. 2. Direct atomic responsibility assignment: An employee is assigned an atomic responsibility without any associated role and the employee then gets the corresponding permissions. 3. Indirect role assignment: an employee is assigned, by direct atomic responsibility assignment all the responsibilities that compose a predefined role, so he is implicitly assigned to the role and he gets the permissions corresponding to those responsibilities. This case reflects the situation where an employee is assigned to more and more responsibilities which happen to the responsibilities predefined in a role. Whereas from an IT point of view, the set of these responsibilities correspond to a role, the employee does not have the title corresponding to the role, from an organizational viewpoint.

The direct role assignment corresponds to the user-role assignment mechanism proposed in RBAC. The advantage of this solution a large number of permissions for users are granted or managed. For example, suppose that the role of project manager is composed of three responsibilities: - management of the team, - management of the project outcomes, - management of the budget.

The employee who is assigned to that role receives all the permissions necessary for the management of the budget, the management of the team, and the management of the outcomes. If a new responsibility is added to the role, the employee is automatically assigned to it.

The direct atomic responsibility assignment: the user is assigned to an atomic responsibility and receives the permissions necessary to perform the tasks linked to that responsibility. E.g. an employee who is not project manager but who however performs the management of the outcomes is assigned responsibility for that task and receives the permissions necessary to perform it. This situation could occur for example in the case where the project manager assigns the management of the outcomes to a subaltern. In RBAC, representing this situation requires the definition of an explicit role for the management of outcomes. If the equivalent situation occurs for the budget management and for the team manager, the number of roles could considerably increase and the advantage of using roles for granting or removing permission to a user will diminish.

The indirect role assignment corresponds to a user-role assignment that exists when an employee is assigned to all responsibilities that compose the role. Whereas RBAC only offers the possibility to assign users to roles, the responsibility-RBAC model permits additionally to refine the granting of permissions to atomic responsibilities and to automatically assign an employee to a role when that employee performs all the atomic responsibilities that compose that role. E.g. an employee who is separately assigned responsibility for the budget management, then for the outcomes management, and afterward for the team management is, as result, implicitly assigned to the project manager role. In that perspective, the employee is assigned to a role from an IT point of view but that employee to role assignment is not recognized by the company. Detecting and officially acknowledging that employee to role association (and consequently make it a direct role assignment) is an improvement of the business IT alignment. If a new responsibility is added to the role, then it will be automatically assigned to the employee in the case of direct role assignment but not in the case of indirect role assignment.

There are three types of responsibility/role de-assignment: direct removal of role, direct removal of responsibility and indirect removal of role. In that last case, when all the responsibilities of a role are removed from an employee, this role is from an IT point of view no longer assigned to the employee whereas from an organizational point of view, this employee is still assigned to the role.

The delegation of responsibility is not the same as the removal of responsibility. In the case of delegation, the employee keeps the obligation of supervision [ 12 ].

4.2 Employees’ commitment to the responsibility

In order to explain how the commitment may be included the user to role/responsibility assignment process, a conceptual assignment process is proposed as illustrated in figure 4. When being assigned to a role or to an atomic responsibility, the employee needs to explicitly commit to the achievement of the task(s) related to the role or to those related to the atomic responsibility. This concept of commitment does not exist in RBAC as it considers the assignment of an employee to a role as an action performed solely by the employee‟s manager. Based on our review of the significance of the commitment in section 3.3 and according to the responsibility model, we propose to integrate the commitment in the employee to responsibility assignment process. The stakeholders involved in that process are indicated in figure 3 as grey boxes. The employee is assigned responsibility to achieve a task by the delegator who remains responsible and accountable for the management of the task, as in CobiT [34]. The employee’s manager is responsible for the management of the employee. Sometimes the task manager and the employee's manager is the same person. The RBAC administrator is the security officer who manages the access rights.

An employee to responsibility assignment process may start with a request from a delegator to transfer the obligation related to a task to an employee (figure 4). This transfer is possible if the employee„s manager accepts the assignment of the responsibility to the employee and if that employee explicitly commits to fulfill the task. The first condition corresponds to a double control which is: the employee availability and the employee capability. In some cases, the employee is also the manager and consequently, decides whether to accept or reject new responsibilities according to availabilities. The second condition corresponds to the commitment pledged by the employee according to his perception of the environment, guarantees received, interest in the task, etc. (see commitment antecedent in section 3.3).

Once the delegator receives the agreement from the employee‟s manager and the commitment from the employee, the delegator requests the RBAC administrator to provide the permissions needed to achieve the task. As soon as the permissions are granted, the employee is assigned the responsibility (figure 4).

4.3 Responsibility-RBAC representation with OWL

The Web Ontology Language OWL is a semantic markup language for publishing and sharing ontologies on the Web. OWL defines classes, properties (binary relation that specifies class characteristics), instances (individuals that belong to the classes) and operations. Recent research efforts [ 8,9 ] concern the translation of RBAC model onto policy languages using OWL. [ 8 ] argues that Policy languages grounded in Semantic Web technologies allow policies to be described over heterogeneous domain data and promote common understanding among participants who not use the same information, and using OWL will help in developing security frameworks with well understood and verifiable security properties for open, dynamic environments, which require coordination across multiple organization […].

To represent the responsibility-RBAC model and remain aligned with the current research, we retain some elements of the ROWLBAC representation and extend it with the definition of a new domain for the responsibility-RBAC model, called rrbac (figure 5). ROWLBAC provides following classes: Action, Subject, Object (lines 1 to 3) and two subclasses of action: permission and prohibition (lines 5 to 8). We also prefer the representation of the role as a class (1st approach of [ 9 ], line 4) and the representation of the separation of duty (SoD) by the property disjointWith. The SoD is the concept of having at least two people required to complete a task to prevent too much power for a single person. In order to bypass the addition of new rules and to avoid the problem of detection of constraint violation by the DL-reasoner (see section 5), the SoD is represented at the responsibility layer. SoD can be static (SSoD) or dynamic (DDoD) if it is function of the run time environment. We do not consider the representation of the dynamic SoD in this paper. To represent the responsibility in the new rrbac domain a new owl class is needed (line 12). The user to responsibility and the responsibility to role assignments are represented by lines 13 to 18. 1 Action a rdfs:Class 2 Subject a rdfs:Class 3 Object a rdfs:Class 4 rbac:Role a owl:Class 5 PermittedAction rdfs:subClassOf Action 6 owL:disjonctionWith ProhibitiedAction 7 ProhibitiedAction rdfs:subClassOf Action 8 owL:disjonctionWith PermittedAction 9 Subject rdfs:property, owl:FunctionalProperty 10 rdfs:domain Action 11 rdfs:range Subjects 12 rbac:responsibility a OWL:Class 13 rbac:role owl:ObjectPropety rdf:ID=”isComposedOf” 14 rdfs:domain rbac:role 15 rdfs:range rrbac:responsibility 16 rrbac:responsibility owl:ObjectPropety rdf:ID=”isAssignedTo” 17 rdfs:domain rrbac:responsibility 18 rdfs:range rrbac:employee Fig. 5. Responsibility-RBAC representation in OWL Enhancement of Business IT Alignment 71

5 Related work regarding the translation of RBAC into policy

This section explains how our approach handles the weakness of other ones related to the translation of RBAC into policy. From the existing work, we focus our review on what we consider are the two most significant ones: ROWLBAC and XACML+OWL. In ROWLBAC [ 9 ], Finin et al. propose two approaches to define an OWL domain to represents RBAC. In the first approach, the role is considered as a class. The hierarchy between roles is represented using subClassOf and the SoD is represented using the property disjointWith. The association of permission or prohibition to role is achieved with an OWL class expression equivalent to our representation of the permission to responsibility assignment. The second approach (figure 7) models a role as an instance of the generic role and uses the ObjectProperty role to link a subject to her possible role (lines 2 to 4). The hierarchy between roles, SoD and the permission to role association is represented by the creation of a new property, respectively: subRole (lines 5 to 7), ssod (for static SoD, lines 8 to 10), dsod (for dynamic SoD) and permitted (lines 11 to 13). Figure 8 illustrates that second approach. 1 rbac:Role a owl:Class 2 rbac:Role owl:ObjectProperty 3 rdfs:domain rbac:Subject 4 rdfs:range rbac:Role 5 rbac:subRole owl:TransitivePropety 6 rdfs:domain rbac:Role 7 rdfs:range rbac:Role 8 rbac:ssod owl:symmetricProperty, owl:TransitiveProperty 9 rdfs:domain rbac:Role 10 rdfs:range rbac:Role 11 rbac:permitted rdfs:propety 12 rdfs:domain rbac:Role 13 rdfs:range Action

For Ferrini et al. [ 8 ], the analysis of both ROWLBAC representations [ 9 ] shows that the first approach has the disadvantage of being inconsistent when 2 classes (Di and Dj) are at the same time included (according to the role-hierarchy) and subject to SoD. Ferrini et al. also uses the ROWLBAC second approach to model RBAC in OWL (namely, the association between a subject and a role is represented by the ObjectProperty hasRole(subject,Role)). However, this has the disadvantage that constraints applying to properties to bind roles together (such as for DSoD or SSoD) is not handled by the standard DL-reasoner [ 8 ]. Ferrini et al. defines a framework to integrate XACML and OWL ontologies for supporting RBAC. It proposes to decouple the management of constraints such as the SoD from the specification and enforcement of XACML policies. The framework includes a critical module to support the DSoD that is based on an obligation to update the ontology with the information related to permissions granted to a subject. The principle is that when a DSoD exists and when a permission has already been granted to a subject, the obligation to update the ontology for another permission (that may not be assigned to the subject during the same session) will fail because it results in an inconsistency in the ontology. The failure of that obligation results in the denial of the second permission.

In XACML+OWL, a role is represented as a class and the hierarchy by the ObjectProperty subRoleOf (Role, Role). The SoD is represented with the property disjointWith. The disadvantage is that it solves the translation of the SoD constraint with the manipulation of an obligation generator module that supports the automatic creation of policy. This solution is not simple and could be complex to deploy in practice.

The responsibility-RBAC model proposes an innovative approach to represent both of those constraints: - In RBAC, the SoD is positioned at the role level and specifies that two roles may not be activated together. We position the SoD at the responsibility level (figure 3) and state that two responsibilities may not be activated together. This improvement limits the SoD strictly to the concerned responsibilities and allows an employee to remain assigned to many roles under the condition that all responsibilities that compose that roles respect the SoD constraint. If this is not the case, conflicting responsibilities must be assigned to another employee. - RBAC positions the concept of role-hierarchy at the role level (figure 3). We keep it as it is, since we agree that the hierarchy reflects the structure between job functions.

6 Conclusions and future works

In this paper we have proposed improvements to some aspect of business IT alignment by refining the assignment of permissions to users based on their business responsibilities. To achieve that, we have proposed an extension to RBAC with responsibility aspect to form the responsibility-RBAC model.

The main contributions are: the optimization of the number of roles by enhancing RBAC with the concept of responsibility and the association of permissions to responsibility, requiring an employee‟s explicit commitment regarding the tasks they are responsible for, and the representation of the responsibility-RBAC in OWL, including a new perspective to represent the constraint of SoD and hierarchy.

Future work will complete the innovative responsibility-RBAC model, deal with some of the above listed issues such as the translation of the model onto policies and evaluate our proposals with real case studies.

References

[1] Feltus , C. , Petit , M. , and Dubois , E. 2009 . Strengthening employee's responsibility to enhance governance of IT: COBIT RACI chart case study . In Proceedings of the First ACM Workshop on information Security Governance (Chicago, Illinois, USA, November 13 - 13 , 2009 ). WISG '09. ACM , New York, NY, 23 - 3

[2] Ferraiolo , D. F. , Sandhu , R. , Gavrila , S. , Kuhn , D. R. , and Chandramouli , R. 2001 . Proposed NIST standard for role-based access control . ACM Trans. Inf. Syst. Secur. 4 , 3 (Aug. 2001 ), 224 - 274 .

[3] Yang , C. 2007 . Designing secure e-commerce with role-based access control . Int. J. Web Eng. Technol. 3 , 1 (Dec. 2007 ), 73 - 95

[4] Kulkarni , D. and Tripathi , A. 2008 . Context-aware role-based access control in pervasive computing systems . SACMAT '08. ACM , New York, NY, 113 - 122 .

[5] Sandhu , R.S. , Bhamidipati , V. , Munawer , Q. , The ARBAC97 Model for Role-Based Administration of Roles , TISSEC, 1999

[6] Sandhu , R. S. and Bhamidipati , V. 1998 . The URA97 Model for Role-Based User-Role Assignment . IFIP Tc11 Wg11.3 Eleventh international Conference on Database Securty Xi: Status and Prospects (August 10 - 13 , 1997 ). T. Y. Lin and S. Qian , Eds. IFIP Conference Proceedings, vol. 113 . Chapman & Hall Ltd., London, UK, 262 - 275 .

[7] Sandhu , R. and Bhamidipati , V. 1998 . An Oracle implementation of the PRA97 model for permission-role assignment . 3th ACM Workshop on Role-Based Access Control (Fairfax , Virginia, United States, October 22 - 23 , 1998 ). RBAC '98. ACM , New York, NY, 13 - 21 .

[8] Ferrini , R. and Bertino , E. 2009 . Supporting RBAC with XACML+OWL . In Proceedings of the 14th ACM Symposium on Access Control Models and Technologies (Stresa , Italy, June 03 - 05, 2009 ). SACMAT '09. ACM , New York, NY, 145 - 154 .

[9] Finin , T. , Joshi , A. , Kagal , L. , Niu , J. , Sandhu , R. , Winsborough , W. , and Thuraisingham , B. 2008 . ROWLBAC: representing role based access control in OWL . SACMAT '08. ACM , New York, NY, 73 - 82 .

[10] Cholvy , L. , Cuppens , F. , and Saurel , C. , Towards a logical formalization of responsibility , Sixth International Conference on Artificial Intelligence and Law , pages 233 - 242 , 1997 .

[11] Dobson , J. and Martin , D. , Enterprise Modeling Based on Responsibility , TRUST IN Technology: A Socio-Technical Perspective , Clarke, K. , Hardstone , G. , Rouncefield , M. and Sommerville , I., eds., Springer, 2006 .

[12] Sommerville , I. , Lock , R. , Storer . T. and Dobson , J. , Deriving Information Requirements from Responsibility Models , 21st International Conference, CAiSE 2009 , Amsterdam, The Netherlands, June 8-12, 2009 . ISBN 978-3- 642 -02143-5.

[13] Fox , J. A. , The uncertain relationship between transparency and accountability" (August 1, 2007 ). Center for Global, International and Regional Studies . Reprint Series. Paper CGIRS-Reprint- 2007-2.

[14] Stahl , B. C. & Wood , Ch. Forming IT Professionals in the Internet Age: A Critical Case Study" In: Yoong, Pak & Huff, Sid (eds.) ( 2006 ) : Managing IT Professionals in the Internet Age . Idea Group, Hershey, PA: 120 - 139

[15] Laudon , K.C. and Laudon , J.P. ( 1999 ), Essentials of Management Information Systems, 4th edition London et al., Prentics Hall.

[16] Vernadat F. B. , Enterprise Modelling and Integration , Chapman & Hall, London ( 1995 ), ISBN 0-412-60550-3

[17] Yu , E. S. and Liu , L. 2001 . Modelling Trust for System Design Using the i* Strategic Actors Framework . Workshop on Deception, Fraud, and Trust in Agent Societies Held During the Autonomous, Eds. Lecture Notes In Computer Science , vol. 2246 . SpringerVerlag, London, 175 - 194 .

[18] Qingfeng He , Annies I . Antón, A Framework for Privacy-Enhanced Access Control Analysis in Requirements Engineering , REFSQ'03, Austria , June 2003 .

[19] Roeckle , H. , Schimpf , G. , and Weidinger , R. 2000 . Process-oriented approach for rolefinding to implement role-based security administration in a large industrial organization . RBAC '00. ACM , New York, NY, 103 - 110 .

[20] Meyer, J.P. & Allen , N.J. ( 1991 ). A three component conceptualization of organizational commitment . Human Resource Management Review . 1 , 61 - 98

[21] Vandenberghe , C. , Bentein , K. , Stinglhamber , F. , Affective commitment to the organization, supervisor, and work group: Antecedents and outcomes , Journal of Vocational Behavior , Volume 64 , Issue 1 , February 2004 , Pages 47 - 71

[22] Mowday , R.T. , Porter , L. W. , Steers , R. M. ( 1982 ), Employee-Organization Linkages: The Psychology of Commitment, Absenteeim, and Turnover . New York: Academic Press.

[23] Buchanana , B. , II. ( 194 ), Building organizational Commitment: The Socialization of Managers in work organizations , Administrative science Quarterly , 19 , pp. 533 - 546 .

[24] Hall , D. ( 1977 ), Organizational Identification as a function of Career Pattern and Organizational Type , Administrative Science Quarterly, 17 , pp. 340 - 350 .

[25] Lio , K. ( 1995 ), Professional Orientation and Organizational Commitment among Employees: an Empirical Study of Detention Workers , Journal of Public Administration Research and Theory, 5 , pp. 231 - 246 .

[26] Niehoff , B. P. , Enz , C.A. , Grover , R. A. ( 1990 ), The Impact of Top-Management Ctions on Employee Attitudes and Perceptions , Group & Organization Studies , 15 , 3 , 337 - 352 .

[27] Florkowski , G. , Schuster , M. ( 1992 ), Support for Profit Sharing and Organizational Commitment: A Path Analysis , Human Relations , 45 , 5 , pp. 507 - 523 .

[28] Blau , G. J. ( 1985 ), The measurmement and Prediction of Career Commitment , Journal of Occupational Psychology , 58 , pp. 277 - 288 .

[29] Pfeffer , J. ( 1998 ). The Human Equation . Boston, MA., Harvard Business School Press.

[30] Meyer, J. P. Allen , N. J. ( 1984 ), Testing the „Side-Bet Theory‟ of Organizational Commitment: Some Methodological Considerations , Journal of Applied Psychology , 69 , pp. 372 - 378

[31] Porter , L.W. , Steers , R. M. , Mowday , R. T., Boulian , P. V. ( 1974 ), Organizational Commitment, Job Satisfaction, and Turnover Among Psychiatric Technicians , Journal of Applied Psychology , 59 , pp. 603 - 9 .

[32] Williams , E.S. , Rondeau , K.V. , Francescutti , L.H. , Impact of culture on commitment, satisfaction, and extra-role behaviors among Canadian ER physicians , Leadership in Health Services, 2007 , vol. 20 , Issue 3 , 147 - 158 .

[33] Zhang , D. , Ramamohanarao , K. , Versteeg , S. ,Zhang, R. RoleVAT: Visual Assessment of Practical Need for Role Based Access Control , ACSAC 2009 .