Enterprise architecture enhanced with responsibility to manage access rights case study in an eu institution

15 pages
8 views

Please download to get full document.

View again

of 15
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
1. Enterprise Architecture Enhanced with Responsibility to Manage Access Rights - Case Study in an EU Institution Michaël Petit* , Christophe Feltus*,† and François…
Transcript
  • 1. Enterprise Architecture Enhanced with Responsibility to Manage Access Rights - Case Study in an EU Institution Michaël Petit* , Christophe Feltus*,† and François Vernadat‡ * PReCISE Research Centre, Faculty of Computer Science, University of Namur, Belgium. † Public Research Centre Henri Tudor, Luxembourg, Luxembourg. EE-Team1 , Luxembourg, Luxembourg. ‡ Directorate for Information & Technology, European Court of Auditors, Luxembourg. mpe@info.fundp.ac.be, christophe.feltus@tudor.lu, francois.vernadat@eca.europa.eu Abstract. An innovative approach is proposed for aligning the different layers of the enterprise architecture of a European institution. The main objective of the alignment targets the definition and the assignment of the access rights needed by the employees according to business specifications. This alignment is realized by considering the responsibility and the accountabilities (doing, deciding and advising) of these employees regarding business tasks. Therefore, the responsibility (modeled in a responsibility metamodel) is integrated with the enterprise architecture metamodel using a structured method. The approach is illustrated and validated with a dedicated case study dealing with the definition of access rights assigned to employees involved in the user account provisioning and management processes. Keywords: Access rights management, Business/IT alignment, Enterprise architecture, Responsibility, Case study. 1 Introduction Access rights management is the process encompassing the definition, deployment and maintenance of access rights required by the employees to get access to the resources they need to perform the activities assigned to them. This process is central to the field of information security because it impacts most of the functions of the information systems, such as the configuration of the firewalls, the access to the file servers or/and the authorization to perform software operations. Furthermore, the management of access rights is complex because it involves many employee profiles, from secretaries to top managers, and concerns all the company layers, from the business to the technical ones. On one hand, access rights to IT components must be defined based on functional requirements (defining who can or must use which functionality) and, on the other hand, based on governance needs (defining which 1 The Enterprise Engineering Team (EE-Team) is a collaboration between Public Research Centre Henri Tudor, Radboud University Nijmegen and HAN University of Applied Sciences. www.ee-team.eu
  • 2. responsibility exists at the business level). The functional requirements advocate that, to perform an activity, the employee must hold the proper access rights. The governance needs are those defined by governance standards and norms and those aiming at improving the quality and the accuracy of these access rights [1]. Practically, one can observe [2] that the existing access control models [3, 4, 5, 6, 7, 8] and rights engineering methods [9, 10, 11] do not permit to correctly fulfill these needs, mostly because they are handled at the technical layer by isolated processes, which are defined and deployed by the IT department or by an isolated company unit that, generally, does not consider their management according to the governance needs. To address this problem, the paper proposes an approach based on the employees' responsibilities that are identified and modeled by considering these governance needs. On one hand, the modeling of the responsibility concept permits to consider several dimensions of the links that associate an employee with the activities he/she has to perform. On the other hand, the integration of the responsibility in a business/IT alignment method, for the engineering of access rights, permits to engineer and deploy the rights strictly necessary for the employees, thereby avoiding too permissive (and possibly harmful) access rights. Enterprise architecture frameworks (EAFs) can be used to model the interrelations between different abstraction layers of a company (e.g. the business, the application and the technical layers) and, according to different aspects such as behavior, the information or the static structure [12]. These models provide views that are understandable by all stakeholders and support decision making, highlighting potential impacts on the whole enterprise. For instance, the enterprise architecture models can be used to understand the impact of a new business service integrated in the business layer on the technical layer and, consequently, enable analysis of some required server capacity. Conversely, the failure of a server has an impact on one or more applications and therefore on business services. The enterprise architecture models support analysis of the impact of various events or decisions and as such the improvement of alignment. For supporting the alignment between the enterprise layers, the EAFs have undergone major improvements during the first decade of the 2000’s and some significant frameworks have been developed such as ArchiMate [12], the Zachman framework [13] or TOGAF [14]. Even if the advantages of EAFs are not to be demonstrated anymore, the high abstraction level of the modeled concepts and of the links between these concepts makes it sometimes difficult to use the EAFs to perform, verify or justify concrete alignments. In particular, EAFs do not permit to engineer precisely the access rights provided to the employee at an application layer based on the specification from a business layer. The paper proposes a contribution to help solving the problem of alignment of access rights with business responsibility originating from governance requirements. The solution extends a particular EAF promoted by the European Commission and used at the European Court of Auditors (ECA) with concepts for representing responsibility at a business level. This extension is obtained by integrating the ECA EA metamodel with the responsibility metamodel of our previously developed Responsibility Modeling Language [2, 15]. The foreseen advantage of integrating both is the enhancement of the alignment among the concepts from the business perspective, the concepts from the application perspective and the concepts from the technical perspective (see Sect. 3). Ultimately, this alignment will support the
  • 3. definition of the access rights to be provisioned to employees, based on their responsibilities. The applicability of the improved metamodel is demonstrated through a case study performed in a real setting. The paper is structured as follows. In the next section, the responsibility metamodel is introduced. In Section 3, the ECA EA metamodel is presented and, in Section 4, both are integrated. In section 5, a case study related to the User provisioning and User account management processes is presented. Finally, in Section 6, some conclusions are provided. 2 Modeling responsibility The elaboration of the responsibility metamodel (Fig. 1) has been performed on the basis of a literature review. As explained in previous papers [2, 15], in the first place, it is analyzed how the responsibility is dealt with in information technology professional frameworks, in the field of requirements engineering and role engineering and in the field of access right and access control models [15]. Then, this literature review was completed with an analysis of a state of the art on responsibility in the field of Human Sciences. Fig. 1. The responsibility metamodel UML diagram.
  • 4. The responsibility metamodel and its most meaningful concepts have been defined in previous works of the authors [16]. The most significant ones, for access rights management, are: the concept of responsibility, which is composed of all accountabilities related to one single business task and that, in order to be honored, require rights (the resources provided by the company to the employee, among which the access rights to information) and capabilities (the qualities, the skills or the resources intrinsic to the employee). The accountability represents the obligation related to what has to be done concerning a business task and the justification that it is done to someone else, under threat of sanction(s) [16]. Three types of accountabilities can be defined: the accountability of doing which concerns the act of realizing a business task, the accountability of advising which concerns the act of providing consultancy to allow the realization of the task and the accountability of deciding which concerns the act of directing and making decisions and providing authorization regarding a business task. An employee is assigned to one or more responsibility, which may be, additionally, gathered in business role(s). 3 ECA EA metamodel To support the management of its information systems (IS), the European Commission has developed a dedicated architecture framework named CEAF2 that has been deployed in several other European institutions and especially the European Court of Auditors (ECA). The particularity of the CEAF is that it is business and IT oriented and provides a framework for the business entities in relation with IT usage and supporting infrastructure. Considering the business as being at the heart of the framework allows continual business/IT alignment. In addition to its four perspectives, namely “business”, “functional”, “application” and “data”, the CEAF also contains a set of architecture standards that gather methods, vocabulary and rules to comply with. One such rule is, for instance, at the business layer, that the IT department of ECA (DIT) responsible for the management of information technology, needs to understand the business activities to automate them. The DIT has defined its own enterprise architecture metamodel, the ECA EA metamodel based on the CEAF (see Fig. 2). This ECA EA is formalized using an entity-relationship model and is made operational using the Corporate Modeler Suite3 . It is made of the same four vertical layers as the CEAF, each representing a perspective in the architecture, i.e.: The business layer, formalizing the main business processes of the organization (process map and process flows in terms of activities). The functional layer, defining the views needed to describe the business processes in relation with business functions and services. The application layer, describing the IT applications or ISs and the data exchanges between them. The technical layer, describing the IT infrastructure in terms of servers, computers network devices, security devices, and so forth. 2 CEAF means European Commission Enterprise Architecture Framework. 3 Modeler Suite from CaseWise (http://www.casewise.com/products/modeler)
  • 5. Each layer includes a set of generic objects, relevant for the layer, and may contain different types of views. Each view is based on one diagram template (Fig. 2). The concepts which are relevant in the context of this paper (i.e. to be integrated with the one of the responsibility metamodel) are described in the next section. Fig. 2. ECA EA metamodel UML diagram 4 Integrated ECA EA-responsibility metamodel In this section, the integration of the ECA EA metamodel with the responsibility metamodel is presented. The method proposed by [17] was used for integrating the metamodels. The three steps of the method are (1) preparation for integration, (2) investigation and definition of the correspondences and (3) integration of both metamodels. 4.1 Preparation for integration Preparing the integration first goes through a primary activity for selecting the subset of concepts from the metamodels relevant for integration. Secondly, a common language for representing both metamodels is selected. 1) Subset of concepts concerned by the integration This activity of selecting the appropriate subset of concepts considered for the integration has been added to the method of [17] and is required to address the
  • 6. concepts from the metamodels that are meaningful for the assignment of accountabilities regarding business tasks to the employees and for the definition of the rights and capabilities required therefore. The subset of concepts concerned by the integration, in the ECA EA metamodel of Fig. 2, includes: The concept of role. This concept is used, according to the ECA EA metamodel documentation, to represent the notion of entity executing a task of a process. It is associated to the concept of a task that it realizes and to the concept of organization to which it belongs. The concept of task. This concept is used to describe how the activities are performed. A task is achieved by a single actor (not represented in the ECA EA metamodel), is performed continuously and cannot be interrupted. The task is associated to the concept of role which realizes it, to the concept of activity that it belongs to and to the concept of function that it uses. The concept of function. This concept enables to break-down an IS in functional blocks and functionality items within functional domains. A function block is defined by the business concepts that it manages on behalf of the IS, combining the functions (functions related to business objects) and production rules of the data that it communicates. It is associated to the concept of task, of IS (the application) that implements it and of entity that it accesses in a CRUD mode (Create, Read, Update and Delete). The concept of entity. This concept represents the business data items conveyed by the IS or handled by an application. In the latter case, it refers to information data. It means that the physical data model implemented is not described in systems/database. The entity is accessed by the function, is associated to flow, is defined by attributes and relationships and is stored in a datastore. The concept of application. This concept represents a software component that contributes to a service for a dedicated business line or for a particular system. Regarding its relation with other concepts: the application is used by the application service, is made of one or more other application(s), uses a technology, sends and receives flow items and implements functions. In the responsibility metamodel (see Sect. 2), the following concepts defined in [16] are kept: responsibility, business role, business task, right, capability, accountability and employee. 2) Selection of a common representation language For the integration step, UML is used because it is precise enough for this purpose, standard and commonly used. As a consequence, the ECA EA metamodel formalized using the entity-relation model has been translated into a UML class diagram (Fig. 2). 4.2 Investigation and definition of the correspondences In [17], the author explains that this second step consists in analyzing the correspondences between classes of the two metamodels. These correspondences exist if correspondences among pairs of classes exist and if correspondences between instances of these classes taken pair-wise can be generalized. The correspondences can be identified by analyzing the semantic definitions of the classes and can be validated on instances in models created by instantiating both metamodels for different case studies. Based on the definitions of concepts and on the authors’ experience with the case study presented in Sect. 5, three correspondence cases between the concepts of the ECA EA metamodel and the responsibility metamodel have been identified:
  • 7. Role from the ECA EA metamodel and business role from the responsibility metamodel: the concept of role in the ECA EA metamodel is represented in the business architecture, is an element that belongs to the organization and realizes business tasks. Hence, it reflects a business role rather than an application role and corresponds, as a result, to the business role of the responsibility metamodel (cf. application role / Role Based Access Control [15]). Entity from the ECA EA metamodel and information from the responsibility metamodel. The concept of entity in the ECA EA metamodel is equivalent to the concept of information from the responsibility metamodel. Instances of both concepts are accessed by a human or by an application component and specific access rights are necessary to access them. Task from the ECA EA metamodel and business task from the responsibility metamodel. The concept of task in the ECA EA metamodel and the concept of business task from the responsibility metamodel semantically have the same meaning. The task from the ECA EA metamodel composes the business architecture and corresponds to a task performed on the business side. According to the definition of the ECA concept, it can be noticed that the task is performed by a single actor. This is a constraint that does not exist in the responsibility metamodel and that needs to be considered at the integration step. 4.3 Integration of metamodels The third step defined in [17] corresponds to the integration of both metamodels. During the analysis of the correspondences between the metamodel concepts, some minor divergences have been observed. Notwithstanding the influence of these divergences, to consider that a sufficient correspondence exists between the elements and to consider them during this third step of integration, these divergences are analyzed in depth and the correspondence rules formalized in order to obtain a well defined and precise integration. Consequently, to construct the integrated metamodel that enriches the ECA EA metamodel with the responsibility metamodel, a set of integration rules has been defined. Therefore, it is decided that (1) when a correspondence exists between one concept from the ECA EA metamodel and one concept from the responsibility metamodel, the name of the concept from the ECA EA metamodel is preserved, (2) when the concept of the responsibility metamodel has no corresponding concept in the ECA EA metamodel, this concept is integrated in the integrated metamodel and the name from the responsibility metamodel is used, (3) when a correspondence exists with conflicts between the definition of the concepts, the concepts are integrated in the integrated metamodel, the name of the concept from the ECA EA metamodel is preserved and additionally integration constraints to be respected are included in the case of using the integrated metamodel. Finally, (4) when concepts differently exist in both metamodels, the integration preferences are motivated case by case. In the sequel, correspondences between classes are first considered and then correspondences between associations between classes. 1) UML Classes integration a) Classes that correspond exactly: The role from the ECA EA metamodel and the business role from the responsibility metamodel exactly match. The entity from the ECA EA metamodel and the information from the responsibility metamodel also exactly match. b) Classes that only exist in one metamodel
  • 8. Employee, responsibility, right and the type of rights to access information, capability and accountability only exist in the responsibility metamodel. Function only exists in the ECA EA metamodel. c) Classes that correspond under constraints The business task from the responsibility metamodel and the task from the ECA EA metamodel correspond partially. In the ECA EA metamodel, a task is performed by a single actor. The ECA EA metamodel description does not define the granularity level of a business task and, for instance, does not define if “doing a task”, “advising for the performance of a task” or “making decision during the realization of a task” are considered as three tasks or as a single one. In the first case, three actors may be assigned separately to each of the three propositions although, in the latter case, only one actor is assigned to it. In the responsibility metamodel, many employees may be assigned
  • Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks
    SAVE OUR EARTH

    We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

    More details...

    Sign Now!

    We are very appreciated for your Prompt Action!

    x