Enforcing Role-Based Access Controls in Software Systems with an Agent Based Service Oriented Approach Feng Chen, Shaoyun Li and Hongji Yang Software Technology Research Laboratory De Montfort University, Leicester, LE1 9BH, England { fengchen, syunli,
[email protected]}
Abstract Access Control is often used to make restrictions to the resources in a system so that these resources can only be accessed by those who have the corresponding privilege. Role-Based Access Controls (RBAC) model introduces roles into Access Control so that the privilege is assigned to role and Access Control can be managed easily by defining the role of the users and inheritance structure of the roles. Although the RBAC model has been well accepted, it turns out to have some problems in applying RBAC to an existing system: an existing system is generally not organised in roles; it is very hard to add the Access Control functions to each module of an existing system. In this paper, an agent-based service oriented approach that helps existing systems be migrated to RBAC for software evolution is proposed. The architecture and working flow of the approach are presented and an example showing how to use the proposed framework and methodology is illustrated.
Keywords: Multi-Agent System (MAS), Service Oriented Computing (SOC), Role-Based Access Control (RBAC), Re-engineering, Legacy System
1. Introduction Along with the popularity of the Internet and development of the World Wide Web, higher security standard is required. Security technology for computer and communication system has attracted much attention to every country’s government and security agency. Almost all of an organisation’s sensitive data are nowadays stored in its software systems. Authentication and authorisation mechanisms are necessary to protect these data from unauthorised access, which are referred to as Access Control. Access Control is often used to make restrictions to the resources in a system so that these resources can only be accessed by those who have the corresponding privilege. Role-Based Access Controls (RBAC) model introduces roles into Access Control so that the privilege is assigned to role and Access Control can be managed easily by defining the role of the users and inheritance structure of the roles. Although the RBAC model has been well
accepted, RBAC is mainly used during the development of new software systems. However, constant innovation of information technology and ever-changing requirements relegate more and more existing software to legacy status. Organisations are in fear of replacing their legacy systems. A major reason why organisations fear the replacement of legacy information systems is that those legacy systems are enormously valuable assets. Having stood the test of time and evolved, they provide the most accurate statement of current business practices. Legacy systems, then, are not an issue that will simply be given up and this raises additional questions that must be addressed: Can the RBAC be used to enforce the high-level security and privacy policies for a legacy system? How can a legacy system be integrated to RBAC? How can a promising RBAC portal solution be offered if two organisations are merged? The growing demands of Business to Business collaborations, for dynamically integrating heterogeneous systems with minimum cost, have fuelled this challenge. In this paper, research on how to apply RBAC model to enhance the safety of an existing system is explored. Section 2 surveys some basic concepts discussed in this research. Section 3 proposes an agent-based service oriented approach to enforce RBAC in legacy systems. The architecture and working flow of the approach are presented. Section 4 illustrates an example on how to use the proposed framework and methodology, and finally in Section 5, conclusion is drawn based on the analysis and further research directions are discussed.
2. Basic Concepts 2.1. Role-Based Access Controls (RBAC) There are three common security goals: confidentiality, integrity and availability [14]. Confidentiality means that information is not disclosed to unauthorised users. Integrity means that unauthorised users cannot modify information. Availability means that an authorised user can always access the information legitimately. The function of Access Control is one of the major security mechanisms used to achieve confidentiality, integrity and privacy in software systems [6]. Access Control paradigms can be broadly grouped into three main policy categories: Discretionary Access Control (DAC) [15], Mandatory Access Control (MAC)
[20], and Role-Based Access Control (RBAC) [4, 5, 7]. Provisioning for DAC systems requires administrators to tailor the control profile for each additional user. The MAC systems provide access solely on global rules and attributes. Both of them require significant provisioning and administrative time. Conversely, a RBAC paradigm for the system can reduce the number of operations associated with granting user privileges since it attempts to mirror the logical controls of the business [9]. RBAC systems can reduce administrative operations by 50% to 90% over DAC systems and MAC systems. This leverage is achieved by reducing the number of operations for each additional user or entitlement change [1]. The RBAC systems have received increased attention in commercial applications. The RBAC model is defined in terms of four model components: Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a RBAC system. Figure 2-1 without red “Role Hierarchy” parts shows the structure of Core RBAC, which includes user-role assignment and permission-role assignment relations. In addition, Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately [7].
to roles that are activated as part of a user’s session [7]. Although the RBAC model is well accepted, it turns out to have some problems in applying RBAC to an existing system: an existing system is generally not organised in roles; it is very hard to add the Access Control functions to each modules of an existing system.
2.2. Service Oriented Computing Distributed, heterogeneous systems running on different platforms are becoming very common, which are particularly difficult to evolve since the elements are written in different languages and the operational environment is heterogeneous and distributed. Security as a non-functional requirement is critical to distributed heterogeneous systems. Adding such “non-functional” features to existing systems is especially hard. The required modifications are scattered through the implementations of the different components. Their design and implementation is also obscured by code delocalisation [18]. A great deal of attention has been focused upon service oriented computing, both in software companies as well as academic research groups. Software services are emerging as a new “standard” architectural style and are being promoted as the next big step forward in software engineering [2]. Services have various characteristics, such as discoverability and dynamically binding, self-contained, modular and composability. Services stress interoperability with coarse-grained interfaces. Since Service Oriented Architecture (SOA) separates the service’s implementation from its interface, the service implementation can be adapted easily to accommodate changing needs, which means the system is able to evolve without breaking applications that consume the service [21]. As a good example of SOA, Web Services are extremely attractive because they can effectively address the demand for short development cycles, distributed development and global user base [16].
2.3. Agent and Multi-Agent System Figure 2-1. Hierarchical RBAC [7] The Hierarchical RBAC component adds relations for supporting role hierarchies as shown in Figure 2-1. Hierarchies are a natural means of structuring roles to reflect an organisation’s lines of authority and responsibility. The Static Separation of Duty Relations adds exclusivity relations among roles with respect to user assignments. Because of the potential for inconsistencies with respect to Static Separation of Duty Relations and inheritance relations of a role hierarchy, the Static Separation of Duty Relations model component defines relations in both the presence and absence of role hierarchies. The fourth model component, Dynamic Separation of Duty Relations, defines exclusivity relations with respect
There are many existing definitions of agent in the literature but none of them is commonly accepted and it varies from researchers to researchers. However, an increasing number of researchers find the following characterisation useful [10, 11, 19]: an agent is an encapsulated computer system that is situated in some environment and that is capable of flexible, autonomous action in that environment in order to meet its design objectives. The definition offered here concentrates on necessary, rather than sufficiency. Agents are often deployed in environments in which they interact, and maybe cooperate, with other agents (including both people and software) that have possibly conflicting aims. Such environments are known as Multi-Agent Systems (MAS) [12]. A MAS is defined as a loosely coupled network of entities that work together to
make decisions or solve problems that are beyond the individual capabilities or knowledge of each entity. Agents are a modular way to develop software. Individual agents are easier to construct and understand than large monolithic systems and agent-oriented approaches can significantly enhance the ability to model, design and build complex, distributed software systems. Many researchers proposed the technology of agents to degrade the complexity of problem. An agent paradigm provides a natural and elegant way to model the interactions between the components of the system and hence shows great potential in the security management.
2.4. Agentification Intuitively, if program P is not considered to be an agent according to a specified definition of agent, it is reasonable for the designer to reconfigure program P as an agent in MAS environment. The legacy code can be extended with agent capabilities by agentifying it, which the functionality and data of the existing systems can be migrated to the new agent-based environment [3]. Generally speaking there are three possible agentification approaches [8]: Transducer, Wrapper and Rewrite. The software could be rewritten, but this is a costly approach. Alternatively a separate piece of software called a transducer could be employed to act as an interpreter between the agent communication language and the native protocol of the legacy system, or thirdly, wrapper technique could be used to augment the legacy program with code that enables it to communicate using the inter-agent language.
3. Proposed Approach: Agent-based Service-oriented Recursive Model (ASRM) The goal of this paper is to present a concept model for agent-based service-oriented system analysis and design, which can lead to the concrete implementation of RBAC for existing application. In this section, Agent-based Service-oriented Recursive Model (ASRM) is proposed for this purpose.
9 9 9 9
It should be possible to load or unload the services at runtime, without having to shutdown the agent system. The services should be able to act as an integrating part of the agent middleware, as if they were integrated with it from the start. The services should be easy to develop and configure. The services should be easy to deploy on an existing agent platform.
Inspired by the Agent-Object-Relationship (AOR) model in [17], two basic types of ASRM are defined: external and internal ones. An external ASRM adopts the perspective of an external observer who is observing the agents and their interactions in the problem domain under consideration, Web Services technology is adopted in external model. In an internal ASRM, we adopt the internal view of a particular agent to be modelled. The recursive model means that agents will be designed in the view of services and services will be provided by agent and consumed by the agents. During the system analysis and design stages, external model and internal model will be refined recursively with services. 3.1.1. External Model. The external model provides architecture (as shown in Figure 3-1) for Agent-based Web Services, which consists of an Administrator, Accompanying Agents, Mapping Repository and Web Services interfaces. Other Web Services
Client Code
Profile and Log
9
The services should be self-contained modules, with clearly defined boundaries.
Mapping Repository
Wrapper Administrator
3.1. Architecture: External and Internal Models Services and agents both are a modular way to develop software. It is natural to view large systems in terms of the services they offer, and consequently in terms of the entities providing or consuming services. A number of efforts have recently begun to integrate the agent and Service, which enable agents to use services infrastructure and to extend the service oriented model with the benefits of agent technology. When considering the services from the view of agent, several characteristics are desirable [13]:
Mobile Agent Web Services
Accompanying agents
Legacy Systems
System
Repository
Wrapper
Access
Map
Figure 3-1. Structure of External model The Administrator works as an agent server and gets consumers’ Web Services invocations. It looks up the Mapping Repository to get the corresponding accompanying agents to create the corresponding Web Services. Furthermore, it is essential for Administrator to know the Web Services execution results and log the invoking history. The accompanying agent is responsible
for mapping between the various actors within the model and functions independently of the system. The agent instance executes the appropriate plan or task according to Web Service invoking parameters and depending on the service provider’s circumstances. The agent would interact with provided Web Services autonomously. The improper Web service invocation could result in that nothing can be invocated by Administrator. It is natural that, when re-engineering the legacy system into Web Services, the legacy system can be agentified first so that each target Web service can have at least one “accompanying agent” and one agent can support multiple Web Services according to the logical grouping of activities. 3.1.2. Internal Model. The internal model mentioned here is same as Service Oriented Model (SOM) [16], which focuses on those aspects of the architecture that relate to service and action. The primary purpose of the SOM is to explicate the relationships between an agent and the services it provides and requests. Internal Model is layered from services to tasks, and finally agents (as shown in Figure 3-2). A task is the atomic work item and can be implemented with a service (in complex cases, it may take multiple services to fulfil one task). An agent is a person, organisation or software that performs a task by fulfilling a service or multiple services. Here, a little difference is that, in this research, a task is defined as a sequence of services, while in SOM, a service is a resource, which performs one or more tasks. There are no conflicts but different viewpoints. More detailed specification can be found in previous work [3].
agent organisation and interaction, without any reference to implementation details. The design phase aims to define the actual structure of the agent system of the services to be provided by each agent, and of the acquaintances’ structure. It is intended to support the development of distributed problem solvers in which the system’s constituent components are known at design time (i.e., it is a closed system) and in which all agents are expected to cooperate toward the achievement of a global goal [22]. For these reasons, Gaia is suitable for supporting the RBAC model. In order to applying Gaia method in this research, three aspects of Gaia model are extended as follows (as shown in Figure 3-3): The first extension is to introduce of organisation model, which is of particular importance in the context of open agent systems. Zhang [22] illustrates the Organisation Model in great detail, where complete specification of computational organisations, three additional organisational concepts (organisational rules, organisational structures, and organisational patterns) are introduced. The second extension is about ontology. Ontologies are a key component in how different agents in a multi-agent system can communicate effectively, and how the knowledge of agents can be developed. Ontologies in this research are used for describing the security policies, which may be shared among agents. The third extension lies between the Agent Model and Services Model. The aim of the Gaia services model is to identify the services associated with each agent role, and to specify the main properties of these services. How an agent realises its services is beyond the scope of Gaia, which will be addressed in the following part.
AGENTS
Requirements Statement
TASKS Analysis
Organisation Model
Roles Model
Interaction Model
SERVICES
Figure 3-2. Structure of Internal model
Design
Agent Model
Services Model
Ontology Model
Acquaintance Model
3.2. Extended Gaia Methodology Figure 3-3. Extended Gaia’s Model The Gaia methodology represents one of the few attempts specifically tailored to the analysis and design of multi-agent systems, and which deals with both the micro (intra-agent, internal model) level and the macro (inter-agent, external model) level of analysis and design [19]. It provides an agent analysis model that introduces the agent abstraction as one of the building blocks describing state and behaviour and uses concepts such as service, actions, goals, and messages. In this methodology, analysis and design are at separated stages. The analysis aims to develop an understanding of the system and its structure, in terms of the roles that have to be played in
The Gaia service model does not prescribe an implementation for the services it documents [19]. The developer is free to employ the services in any implementation framework deemed appropriate. For example, it may be decided to implement services directly as methods in an object-oriented language. Alternatively, a service may be decomposed into a number of methods. The most attractive property of Gaia-based recursive model is that the infrastructure of the service-based agent for agent-based service system is flexible and evolvable.
3.3. Working Process
4. Case Study
The main tasks for a legacy system to be migrated to RBAC are determination of user roles and subsequent assignment for a legacy system. An iterative role reengineering process is required which encompasses three phases: forward engineering, reverse engineering and merging. The extended Gaia method is used for forward engineering phase, which leads to the following system development path:
To illustrate the proposed approach, an example project, “Common Library Management Information System (CLMIS)”, is presented. At the stage of system analysis, Use Cases are still a useful tool to capture the user requirements, and sometimes, it is a natural way for agent system modelling. The Use Cases analysis involves reading and analysing the specifications, as well as discussing the system with potential users of the system. Figure 4-1 shows a Use Cases diagram for CLMIS. In order to simplify the illustration, only parts of Use Cases are displayed and some Use Cases, such as “Maintain” and “Interchange”, could be extended in more details if needed.
9
9
9 9
The first step consists of the identification of the roles in the application domain in terms of the corresponding goals or tasks. Consequently, a role is identified by the main tasks and forms the basis for a specification of agent types. In the second step, organisational structure of the multi-agent system and the coordination among agents to perform a task and the required communication schemes need to be analysed. The third step identifies the main services associated with agent roles. The last step assigns the security policies to identified roles and results in the design of an adequate ontology.
REACT (Re-Engineering for Agent Construction and Transformation) method [3] is used in the reverse engineering phase, which is based on the reengineering technology. The method is achieved by transforming, understanding, evaluating and regenerating a legacy system in such a way that the techniques of decomposition, abstraction and organisation are applied, which can roughly be divided into following steps: 9 9 9 9
The legacy system is analysed and transformed. As a result, a spectrum of abstractions of legacy system, from source code to specification, is generated. Identify the external and internal actors of the application and create the models of role and responsibility. Identify the services and create the models of high-level task. Identify agents based on previous steps.
During the merging phase, role model of legacy system is matched to the role model designed by extended Gaia method. The issue of agentification should be addressed in this step, which involves the integration of existing software components with an appropriate agent-based service interface. Unmatched roles in existing system need to be either merged into existing roles or worked into newly created roles. Note that by definition; each role will be associated with at least one service, which is derived from the list of protocols, activities, responsibilities and the liveness properties of a role.
Borrow Item
Check Account
maintain
Renew Item
Search Item
Borrower
Penalty for Overdue
Reserve Item
Librarian
Deliver
Return Item
Other Library Interchange
Figure 4-1. Part of Use Cases for CLMIS At the system design stage, agent diagrams and service diagrams are established. In this research, a library agent, as an organisation agent in analysis stage, includes the librarian agent (Human Agent) and the software information agent (Software Agent). From the view point of a borrower, a library agent is a service provider agent. From the other library’s view point, a library agent can also be a service consumer agent. At the reverse engineering stage, two catalogues of role in a library are identified as the librarians and the borrowers. Of course, roles can be classified in more detail. Occasionally, another library is also a borrower. All the roles will be mapped to the agents in the external model and all the services will be found out in the internal model. The selected services will be checked if some agents will use them. For example, the service, “CheckCanBorrow”, will be used by librarian agent. As for the Web Service identification, only those services that are exposed to the public should be integrated as Web Services. An agent type is useful when identifying which service should be integrated into Web Services. Normally, the Use Cases with two actors are the first choice, such as “Borrow Web Service” or “Renew Web Service”. The key point is weather the functions of this Web Service can be provided by one service provider agent. The last stage links the results of forward and reverse engineering together. “Roles Proxy Agent” is employed to enforce Access Control between multi-agents so that security mechanisms are separated from the business logic.
“Roles Proxy Agent” is the key component, which need to be implemented as a middleware. Figure 4-2 illustrates the design model for the case study. The low level services are organised by service provider agents. Service provider agents provide Web Services for public access. All Access Controls are assigned by the “Roles Proxy Agent”. Borrower Agent
Other Library
Coarse-grained Services (Web Services) Borrow Web Service
Renew Web Service
Search Web Service
...
Librarian Agent Roles Proxy Agent Information Agent
Other Agent
Fine-grained Software Services Change book status
SetDeliverAddress
...
Book information
Figure 4-2. A Design Model for Case Study
5. Conclusions and Future Work In this paper, an agent-based service-oriented software reengineering approach is proposed, which provides a smooth migration path to RBAC paradigm that can be used to enforce the high-level security and privacy policies into the system. The most attractive property of ASRM is that Service Oriented Computing moves the internal functions to external service so that Access Control policies can be extracted while agent takes advantage of the overall services benefits. Extended Gaia approach which provides Roles Model, Organisation Model and Interaction Model can offer a promising RBAC portal solution if two organisations are merged. This approach is modestly invasive but offers a high return on investment for legacy assets. Although a unified approach to RBAC migration has been presented, many issues need to be addressed: 1. The research in this direction is quite recent and has some distance from resulting into a completely automatic working process. 2. ASRM requires tool support and related practices to validate its applicability. 3. Aspect Oriented Programming (AOP) could be another promising choice for RBAC migration.
References [1] A. Antonio, "Moving to Role Based Access Control," http://www.altametric.com/journal/EntCasePub.pdf, 2006. [2] K. H. Bennett and J. Xu, "Software Services and Software Maintenance," in Proceedings of the 7th European Conference on Software Maintenance and Reengineering (CSMR’03). Benevento, Italy, 2003, pp. 3-12. [3] F. Chen, H. Yang, H. Guo, and B. Xu, "Agentification for Web Service," in Proceedings of the 28th International
Computer Software and Application Conference (COMPSAC'04). Hong Kong, Sept. 2004, pp. 514-519. [4] D. F. Ferraiolo and D. R. Kuhn, "Role Based Access Controls," presented at the 15th NIST-NCSC National Computer Security Conference, Transactions on Information and System Security, 1992. [5] D. F. Ferraiolo and D. R. Kuhn, "An Introduction to Role-Based Access Control," ACM Transaction on Information and System Security, vol. 2(1), 1995, pp. 18-24. [6] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli, Role-Based Access Control: Artech House computer security series, 2003. [7] D. F. Ferraiolo, R. R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli, "Proposed NIST Standard for Role-based Access Control," ACM Transaction on Information and System Security, vol. 4(3), 2001, pp. 224-274. [8] M. R. Genesereth and S. P. Ketchpel, "Software Agents," Communications of the ACM, vol. 37(7), 1994, pp. 49-53. [9] Q. He, "Requirements-Based Access Control Analysis and Policy specification," PhD thesis, North Carolina State University, 2005. [10] N. R. Jennings, "Agent-Oriented Software Engineering," in Proceedings of the 12th International Conference on Industrial and Engineering Applications of AI. Cairo, Egypt, 1999, pp. 4-10. [11] N. R. Jennings, "On Agent-Based Software Engineering," Artificial Intelligence, vol. 117, 2000, pp. 277-296. [12] M. Luck, P. McBurney, and C. Preist, "Agent Technology: Enabling Next Generation Computing: A Roadmap for Agent-based Computing," AgentLink Report, available from http://www.agentlink.org/roadmap 2003. [13] P. J. Marques, "Component-based Development of Mobile Agent Systems," PhD thesis, University of Coimbra, July 2003. [14] C. P. Pfleeger and C. L. Pfleeger, Security in Computing (3rd Edition): Prentice Hall, 2002. [15] R. Sandhu and P. Samarati, "Access Control: Principles and Practice," IEEE Communications, vol. 32(9), 1994, pp. 40-48. [16] W3C, "Web Service Architecture," http://www.w3.org/TR/2004/NOTE-ws-arch-20040211. [17] G. Wagner, "The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behaviour," Information Systems, vol. 28(5), 2003. [18] E. Wohlstadter, B. Toone, and P. Devanbu, "A Framework for Flexible Evolution in Distributed Heterogeneous Systems," in Proceedings of the International Workshop on Principles of Software Evolution, Session 2 (Short Papers): System and Practical. Orlando, Florida, 2002, pp. 39-42. [19] M. Wooldrige, N. R. Jennings, and D. Kinny, "The Gaia Methodology for Agent-Oriented Analysis and Design," Autonomous Agents and Multi-Agent Systems, vol. 3, 2000, pp. 285-312. [20] U. Zdun, "Reengineering to the Web: A Reference Architecture," presented at the 6th European Conference on Software Maintenance and Reengineering (CSMR'02), 2002. [21] Z. Zhang and H. Yang, "Incubating Services in Legacy Systems for Architectural Migration," in Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC'04). Busan, Korea, Nov. 2004, pp. 196-203. [22] Z. Zhang and C. Zhang, Agent-Based Hybrid Intelligent Systems: An Agent-Based Framework for Complex Problem Solving: Lecture Notes in Computer Science Volume 2938, 2004.
