Agent Approaches to Role-Based Security

Draft Paper: Submitted to 13thIFIP 11.3 Workshop on DB Security
CSE Technical Report CSE-TR-01-99

Agent Approaches to Enforce Role-Based Security in
Distributed and Web-Based Computing[*]

S.A. Demurjian, Sr., Y. He, T.C. Ting, and M. Saba[†]

Abstract

In the age of information technology, we are striving to use the information and resources that are available in local distributed computing environments and in global web-based applications. Organizations of all types are seeking to effectively utilize and disseminate information within an entity (organization), by designing and developing dependable and secure distributed computing environments that allow all types of existing and future systems to inter-operate. In this paper, the security of distributed and web-based applications is our primary concern. While many existing access control approaches (mandatory, discretionary, and role-based) can be leveraged for the support of security in distributed and web-based settings, their adherence to a conventional computing model may be a significant disadvantage. In recent years, agent computing has emerged as a new computing paradigm, particularly suited to distributed and web-based applications. The purpose of this paper is to explore agent approaches, focusing on their ability to support role-based security in a dynamic, object-based setting which is suitable for both distributed and web-based applications. The agent approaches differ in their utilization of agents (both stationary and mobile) and the granularity level of the involved classes and objects. We also report on the implementation of one of the agent approaches, that has been accomplished via aglets, which is a Java-based mobile agent model developed by IBM.

1.Introduction

The growth of distributed computing environments and web-based applications deployed in industry, government, and academia continues to increase, as organizations strive to allow information to be utilized in new and innovative ways. Today's and tomorrow's distributed and web-based applications will be comprised of existing legacy, commercial-off-the-shelf (COTS), and database applications that are able to interact with newer or emerging client/server applications, and web-information repositories. The fundamental challenge facing organizations, software architects, system designers, and application builders involves the ability to leverage computing and networking resources, and data and information in existing applications, to construct new dependable and secure distributed and web-based applications. Our focus is on the secure nature of distributed and web-based applications, particularly in venues which promote electronic banking, commerce, information dissemination (push and pull), and so on. Distributed and web-based applications will require researchers and practitioners to design security solutions that expand and transcend available alternatives. Traditional alternatives such as mandatory access control (MAC) [Keef88, Land84], discretionary access control (DAC) [Loch88, Sand96], and role-based security (RBS) [Demu97] may all be useful to some degree as software architects, software engineers, and security engineers work towards the establishment of a cohesive security policy. Agent computing, which first emerged just five years ago [Gene94], has great potential for supporting the design/development of secure distributed and web-based applications.

Agents act on the behalf of individuals (users) to assist in a particular task, hopefully making it easier for users to accomplish what they intended. Software agents, as computing objects have a specific function or responsibility to perform, and can be defined in formal terms to have a state and a behavior with the runtime environment. Software agents have four mandatory properties [Lang98]: ability to sense and react to changes in the environment; autonomous control over its own state and behavior; proactive to achieve specific goals (typically of the user); and, constantly executing within the runtime environment. Stationary agents are restricted to a single computing node in accomplishing their tasks. Mobile agents can migrate to a new location in order to execute their required responsibilities. All agents are like other objects in that they can be created and destroyed. However, agents cannot interact by invoking each others methods; rather, they communicate via message passing. The autonomous and mobile nature of agents make them attractive for security purposes. For example, one scenario could have agents dynamically created from a client application to carry out the secure access to objects across a network. In such a scenario, the agent may go forth and visit multiple nodes to collect/update relevant objects. Security can be included as part of the agent functionality, providing a specificity of role based on the client that has dispatched the agent. Note also that mobile agents are a significant security concern from an execution perspective, due to their potential ability to act as a threat. Our intent in this paper is to present and explore various scenarios for agent approaches to security within a role-based context for distributed and web-based applications.

The work presented in this paper is a progression of our own efforts [Demu97, Demu98, Smar98], with the justification to pursue this effort influenced by other researchers [Hale96, Hale98, Tari98]. In our previous work [Demu98], we explored software architectures alternatives that utilized a client/server paradigm to explore role-based security. While there was distribution in some of the alternatives, the emphasis was on relatively static architectures, which is inadequate for true distributed and web-based applications. There have been efforts to investigate security for distributed objects [Hale96], which has recently been extended to provide a secure distributed object and language programming framework that is suitable for internet-based applications [Hale98]. Another effort has utilized the Distribute Object Kernel (DOK) project as the underlying framework upon which software agents can operate for the design and implementation of distributed security policies [Tari98]. Our most recent effort has explored the capabilities and the potential impact of Java on security for distributed computing [Smar98], which we used as a starting point to explore agent approaches to role-based security, which is the main emphasis of this paper.

The goal of this paper is to explore the potential of agent computing in support of role-based security in a dynamic, object-based setting. For security in distributed and web-based applications to succeed, it is important to leverage existing security techniques in conjunction with emerging approaches to arrive at a solution for the 21st century. The remainder of this paper is organized into three sections. In Section 2, we detail three architectures of agent approaches for role-based security in a dynamic, object setting. In Section 3, we explore our experimental prototyping efforts with one of the architectures presented in Section 2 to clearly demonstrate the feasibility of agent-solutions. Finally, in Section 4 we conclude by offering insight into ongoing efforts and future plans.

2.Agent Approaches to Role-Based Security

The purpose of this section is to present a series of agent approaches that can be utilized to facilitate the role-based access of remote objects by users in distributed and web-based applications. Security for such applications must occur in an environment that may consist of legacy, COTS, database, and new/existing server applications, with clients interested in obtaining access to the remote objects that reside in these various applications. One interesting aspect of security is that its goals are often orthogonal at some level to the goals of distributed computing and web-based computing. Security has the goal of controlling and limiting certain types of interactions while distributed and web-based computing is concerned with enabling interoperation and facilitating access to information. For discussion purposes within this paper, we are assuming a client/server computing model for distributed and web-based applications. Specifically, in our client/server model, a client application is interested in sending a request to access/modify a remote object, with the allowable actions on the remote object dictated by the role of the user (client).

Thus, the scenario is that a client application is making a request to access/modify a remote object, that may be residing in a legacy, COTS, database, or server application. In such a scenario, we want the request to be processed according to the defined security policy for the client application in a dynamic setting. Agents are attractive in such a setting, since they allow autonomous and mobile actions to occur on behalf of a client. In our case, these actions will authenticate the identity and role of the client application, and then dispatch agents that can move across computing nodes for the secure access of remote objects. This section presents three agent approaches that support role-based access for distributed and web-based applications:

  • A baseline agent approach that represents a core set of system components and agents (both stationary and mobile) to facilitate the remote access to an object.
  • A hierarchical agent approach that expands on the baseline approach to spawn a series of multiple agents for simultaneously accessing remote objects in multiple locations.
  • An object-security manager agent approach that extends the hierarchical approach to include the access of multiple remote objects in the same location.

The remainder of this section reviews each approach in detail. Finally, note that while we have employed a role-based paradigm for security, there is nothing in the ideas presented in this section that will restrict our solution.

2.1Baseline Agent Approach

The architecture for the baseline agent approach is presented in Figure 1, and is partitioned into a client computing node (upper half of figure) and a server computing node (lower half of figure). The components and agents are as follows:

  • Client Application (CA): This component is the graphical interface or software tool that is utilized by the user to perform a specific set of tasks. The user is restricted to playing a single role at any time, and both the role and request are passed from CA to the user agent (UA) for processing. Users can access/modify only a single remote object at a time via CA. If multiple remote objects are to be accessed/modified, there must be functionality within CA that allows such a request to be separated into a series of individual object accesses. Agent approaches in Sections 2.2 and 2.3 will consider requests that involve access to multiple remote objects.
  • User Agent (UA): This is a stationary agent that is created upon the request of the client to represent the user. UA receives a request from the client, transforms the request to the proper format, creates the information retrieval agent (IRA), forwards the request to IRA, waits for the processing of the request, collects the results of the request from IRA, and transforms and then returns the results to CA.
  • Information Retrieval Agent (IRA): This is a mobile agent that is created by UA for processing the request of CA. In this baseline approach, the IRA is limited to interacting with the UA on the client side and object security agent (OSA) on the server side. IRA is created and dispatched by UA to access a single remote object on the server side, if permitted by the role of the user.
  • Object Security Agent (OSA): This can be a stationary agent (collection of security objects) or a mobile agent. In either case, OSA enforces the security policy of the object that is based on the permissible actions of each role.
  • Object: The remote object that is available to provide services to CAs.

While the above represents an overview of the capabilities of each component in Figure 1, it is important that we examine UA, IRA, and OSA in greater detail, to fully understand the subtleties involved in their interactions and lifetimes. Moreover, in some situations, there are alternative scenarios that are plausible based on the assumptions and operating environment. Note that authentication of the user must occur prior to the spawning of an IRA to respond to a request; we are assuming that this will take place in either the client application or by UA.

2.1.1User Agent

The user agent (UA) is a stationary agent that is utilized by the client application when the user requests that an action be initiated on his/her behalf. The user, via CA, can only play a single role at any given time. UA is the interaction medium between CA and the mobile IRA. The UA receives a coded request from CA, forwards the request to IRA, and waits for the response from IRA. For the baseline approach of Figure 1, UA receives a single request to access one object. There are two different UA allocations strategies:

  • User-Based Allocation: In this situation, a UA is allocated and dedicated to an individual user when the client application commences and the user logs on to a session. Essentially, a dedicated UA can enforce the single role that the client plays. If multiple CAs are executing on the same client node, then multiple UAs will compete for computing resources.
  • Role-Based Allocation: In a multi-user environment, where multiple users are active, it makes sense to explore an allocation strategy that is based on role. In this situation, dedicated UAs are allocated for each role, and shared by the many users (CAs) that are playing the same role. UAs are allocated whenever there is a request for a user (CA) to play a role, and that role is not supported by an active UA. When a UA is no longer being utilized by any active CA, then it can be de-allocated.

The allocation above is based on the assumption that a user (CA) can only play one role at any given time. If a user can play multiple roles simultaneously, user-based allocation is still feasible, since each UA will embody the security policy for the multiple roles being played. However, role-based allocation becomes problematic. Since the security privileges for a user are spread across multiple UAs, the UAs would be required to communicate to synchronize their activities. Thus, the lifetime of UA can vary based upon different scenarios of CA behavior within a shared client computing node.

2.1.2Information Retrieval Agent

The information retrieval agent (IRA) is a mobile agent that is created by UA on the client side to process the request of the user (from CA). In the baseline agent approach, the request to be processed by IRA will be limited to a single remote object. As a mobile agent, IRA is able to move to the host computer (server side) where the object resides that is needed to satisfy the user's request. IRA carries the user request and the current role, which are both needed to interact with the object-security agent (OSA) to process the request. In the baseline agent approach, IRA moves to the destination and exchanges information with OSA. Once the IRA has received a response (success or denied access) from OSA, it takes that response, ceases its action, and moves back to the client side to return the result to UA, which will then forward the response to CA. As in Section 2.1.1, there are two different scenarios for the lifetime of IRA that share a common basis, IRA is allocated by UA for the first request of a remote object by CA.

  1. IRA stays alive as long as UA is active. In this case, a single IRA can process all requests by a client in a sequential manner, starting a new request only after the current request has been completed. This scenario reduces the overhead associated with creating and destroying a mobile agent.
  2. IRA is de-allocated when it finishes processing a request. In situations were access to remote objects by clients is infrequent, this scenario benefits by not having active, idle agents.

The first scenario will not support multiple active requests being spawned by UA for simultaneous processing by IRA. The second scenario supports such a situation, since multiple independent IRAs can be spawned that move to remote locations to access objects. This will require UA to have additional logic to be able to process a queue of simultaneous requests from the same or different users.

2.1.3Object Security Agent

The object security agent (OSA) can be conceptually regarded as the firewall that separates the remote object from the outside world. OSA embodies the security policy for the remote object, which in our case, is a role-based approach that dictates which role can access which method on the object [Demu97, Demu98]. OSA receives a request to access a remote object via the mobile IRA, and based on the privileges of the role, will either deny or respond to the request. The OSA component can be designed and implemented as either a set of security objects or a mobile agent. If OSA is a set of security objects, it is tightly bound to the class (type) of the remote object, and the supported security policy will be one of the object-oriented role-based techniques we have described in our earlier work [Demu97]. Allocation of OSA in this situation will occur when the remote object is instantiated. If the OSA is an agent, it must be a separate entity from the remote object. The security policy that is supported in this situation can occur at the class (type) or object (instance) levels. In this case, there are a number of strategies for OSA allocation: