Role Based Approach to Data Access in Adhoc ...

Role Based Approach to Data Access in Adhoc Networks Qurban A. Memon and M. Shakeel Laghari College of Engineering, UAE University, Al Ain UAE, [email protected]

Abstract

For example in [8], the author has carried out survey of most recent contribution in the area of data management related to mobile computing. The work surveyed covers areas such as data dissemination, data consistency, location dependent querying, and interfaces. In [9], the authors discuss an application for mobile commerce (mcommerce). Specifically, the authors introduce an infrastructure for m-commerce in a given geographic area using a multi-channel system. The agents have also been explored in this area of wireless environment, for example in [10]. The authors in [10] address data recovery in wireless environment using mobile agents. The authors discuss log managements scheme using forward strategy for logging of application activities for recovery from transactions or when system failure is non-trivial. To address similar environment, another work is reported in [11], where authors address transaction commit for mobile database systems. Specifically, a single phase time out based transaction commit protocol has been presented by authors in any message oriented system, particularly for wireless environment. The authors in [12] propose a work, where they have investigated the efficiency of data access methods, which are limited by an inherent property that data can only be accessed strictly sequentially by users. In order to address buffering and cache issues in mobile databases, a novel approach has been reported in [13], where authors discuss cache retrieval schemes in a mobile computing environment. The issues addressed cover buffering of transaction data during service handoff in mobile computing. Role-based access control (RBAC) has recently received considerable attention as a promising alternative to traditional discretionary and mandatory access controls. There are several mainstream commercially available products that support RBAC in some form. More than any other commercial application software, DBMSs (database management systems) provide access control at several levels of granularity including provision for contentdependent controls. The database management is a prime area which needs a mechanism for management of authorizations or privileges. Not surprisingly DBMSs have taken the lead in providing support for RBAC. The notable contribution related to this work has been reported in [14], where authors compare three (single) commercial database

In this paper we combine concepts of role-based access and databases to specify separation of duty (on wireless networks) as required for database integrity. Specifically, we consider adhoc network environment and discuss role access to network databases. We give a description of the methodology and role based model showing how roles can be assigned and how propagation of permissions is handled. Given this general approach, a system developer can design an authorization model for data access and transfer based on roles in an adhoc environment.

1. Background work

In private networks, the devices within wireless networks may form a local network if they are confined in a small area. In such networks the user may require access to databases anytime anywhere, demanding information such as medical and inventory records [1]. Due to higher bandwidths available in the newer WLAN standards it is not far that database support would be routine for achieving workflow and communication management that include setting up a dynamic infrastructure with changing sizes and authenticated access using certain access control policies [2]. The emergence of new wireless technologies such as 802.11 series WLAN [3] and short-range radio technologies such as Bluetooth [4] have opened new possibilities for the implementation of networks which transcend the conventional bounds of fixed physical networks. To address issues related to adhoc networks, the Internet Engineering Task Force (IETF) [5] is developing mobile adhoc networks (MANET) specification to enable future applications. Currently, organizations are exploring to accept models that tend to use roles rather than conventional, procedural as well as beaurocratic methods [6]. A large number of enterprises have recently started to explore Internet based workflow management systems to help improve their services and decision-making processes [7]. The most important component of access policy is how users, groups and roles are associated with access to corporate resources. Further to our discussions, a lot of work related to database access on wireless channels has been reported.

1-4244-0212-3/06/$20.00/©2006 IEEE

1163

management systems based on RBAC features that have been categorized under three broad areas namely user role assignment, support for role relationships and constraints, and assignable privileges. It is concluded that all three provide support for role hierarchies, but Sybase is the only one to directly support mutual exclusion of roles.

corresponding software running on a trusted computer (i.e., central server) preferably at central location of the organization can be used. Its primary function is to make access control decisions and running functions on behalf of the device it represents. Such network architecture is proposed in Figure 1. Multichannel model: We propose a multichannel model to categorize types of data transfer (sack of simplicity) pertaining to general and role specific use. The UDDI channel includes registry information about the services, given by the central server and propagated by the coordinator device. Each entry in the UDDI channel is identified by a U-key, and information within the channel is customized to fit wireless environments. The service channel contains the description and executable code of each service. Information within the service channel is indexed with a service key to enable better access performance. The data channel is used transfer among network devices. Devices: The device working as Coordinator will have more features in its software component to allow necessary communication with central server for authentication or creating software proxies for network devices. When device enters a network, its proxy is generated at the central server, and a shared key along with resource identifiers corresponding to that specific role are sent back to the device. Whenever a device enters an adhoc network, it downloads UDDI channels content to its device and store it for later use. Caching it avoids frequent access to the channel, and minimizes power consumption of the devices as well. Thus, the organizations need to empower mobile user devices with the ability to: a. discover service and data channel(s) b. download the service code c. find out the way to invoke the service (like which input parameters are required) Proxy: This is a software component running on a central server for each active device on the network. Its main functions are access control decisions, logging of device actions, interfacing with other proxies, and running functions on behalf of the device itself including emergency functions, and status updates. Because of these sophisticated access control and authentication process at proxy, the device remains simple. Central Server: This is a powerful computer, and must be able to supervise many adhoc network(s) at the same time, and be able to create a number of proxies. The link with Coordinator can be handled through an independent wired or wireless connection. Through this server, a set of services can be unleashed to expand the service domain of this network, like connectivity to other private wireless and wired networks. This obviously depends upon the features available within one’s role, which is to be supervised by proxy.

2. Proposed approach

In this section, we address problems that surface after an adhoc network of devices is formed.

2.1 Policy and Database Criteria:

Based on the discussion, we summarize the issues in Table 1. The table lists the issues when adhoc network devices carry respective organizational role during database access within an adhoc network. It should be emphasized that a detailed framework for adhoc network architecture is not under our consideration in this paper. The interested reader is referred to [15] for details on the framework and proposed corresponding architecture. Referring to Table 1, data management (issue 10) can further be elaborated to include certain access policy criteria, as outlined below: a. User/Group/Role: Policy can be defined for groups and roles so user access is relevant to their organizational placement. b. Application and Application Content: Deep packet inspection enables identification of applications regardless of port. c. Standard ACL (Layer 2, 3, and 4): Traditional ACLs, can be defined based on source MAC address, source and destination IP Address and protocol. d. Periodic and Absolute Time: Policies can be defined as valid only during specified time and day ranges, such as every weeknight between 11pm and 3am. Absolute times can be used to create policies that expire on a specific date and time. e. Location: Access policy can be defined based on the direction of traffic, which is a function of the source and destination locations. Based on the criteria in Table 1, the following objectives are set in our approach: • Describe the components in the adhoc network that address all issues to enable seamless computing. • Describe easy to manage role-based access policy that updates automatically as users authenticate or as their roles change in directory services.

2.2 Infrastructure

The adhoc network formation requires that at least one architectural component is present (at all times) to initiate forming of an adhoc network. Thus the member itself (and as such for other members) can create network on its own. However, it needs to conform to the role(s) assigned to such devices. The joining of a device is to be authenticated by a central server owned by the organization. The

1164

Table 1: Summary of issues in database access in an adhoc network 1

Location of database

2

Caching method

3

Temporal cache

4

Cache Retrieval

5

Transaction commit

6

Transaction response time

7

Application data logging

8

Service channel

9

Role based access logging

10

Data management

Description The location of a database affects the access and availability of application data during mobility of a network device. During service handoffs and upon re-entering the adhoc network, cache availability and consistency helps avoiding delays. Availability of a temporal cache enables continuity in running an application across two adhoc networks. Minimizing cache retrieval time helps in continuing the same application, while network device is on the continuous move. Time to minimize transaction commit is very useful to lower the impact of slow and unreliable wireless link. This time is important to speed up the processing of transactions in wireless data broadcast. Managing application log for efficient application recovery shall conform to database limitations and mobile discipline constraints. During adhoc network, communication on existing data channels may affect the cache recovery, application logging or a variety of broadcasts. Retrieval of cache depends upon logging of authorization data from network devices and servers A data management scheme is very important that is based upon a role based model and uses various techniques to address issues 1-9 above.

Mobility: If the device functioning as Coordinator is relatively stationary, then the level of resources in the network is not seriously low. On the contrary, if device with Coordinator is mobile, then it creates a resource problem. However, for short-lived networks, the mobility of device the Coordinator can be allowed if the rate of mobility is considerably lower and is confined within a given geographic area. In case, if Coordinator leaves and another joins in, a new mechanism is to be devised to let all devices know that there is a new Coordinator.

capability in order to enable the device to act as the coordinator. In this case, the membership management will also manage the membership of the specified event and executing the actions specified in the policies when the events occur. Lastly, the event service collects and aggregates events and subsequently forwards them to the policy enforcement, e.g. the triggering of the execution of obligation policies. (RF packets (or UDP/IP) Database

2.3 Access control based on roles

We adopt the terminology and concepts of the well-known family of models [16]. Based on this, the architecture for access control framework is proposed of four components as shown in Figure 2, namely profile management and membership management (combined as user management), protocol management, policy enforcement and an event service. The framework runs on every user’s device. The profile management component maintains the user’s credentials. Users can manage their credentials and device settings through user management interface. In addition, this component also maintains the user’s preferences on which communities the device should automatically join. The membership management component exposes the user management interface to the application level, so that applications can initiate the establishment of a new community, search for communities, as well as joining particular communities. Through this interface, the user can register the services that it is providing to other participants. The membership management component is also responsible for checking the authenticity of the doctrines and enforcing them by extracting and distributing the policy instances to various enforcement components. An optional module, known as coordination service can be dynamically loaded according to the user’s device

Device A

(Central Server)

Device B Device X Coordinator

Mobile Adhoc Network: {Devices: A, B, C, D, X (coordinator)}

Device C

functions: {authetication, list of resource identifiers, (RF packets (or UDP/IP) create proxies etc.}

Device D

Figure 1: Adhoc Network Infrastructure

2.4 Access algorithm for devices: We present an

1. 2. 3. 4.

1165

algorithm that needs to be performed to execute the network access service. Adhoc users generally start by looking for service on their category and role. Algorithm “execute-service”: Find adhoc service having a given category in the local UDDI directory Select a service and retrieve its serviceKey K and compare with the key stored in the event service. Retrieve the frequency of the service channel Listen to the service channel

5.

Download the description and code of the service having K as the service Key. 6. Based on the serviceKey K, determine input parameters (from user management) to initiate access to the network. 7. Proceed to login onto the network. 8. After successful login, retrieve frequency of data channel 9. Download role specification for the device and store it. 10. Execute the service or exchange data with other users on the data channel of the network.

case of Coordinator, additional overhead is the data management. As adhoc network devices are particularly smaller in number, this additional overhead is not expected to be high at any given time. On the other hand, advantages gained are access based on policy of the organization, and simplicity at network administration.

4. References

[1] Demiris G, “Disease Management and the Internet”, Journal of Medical Internet Research, 2004; Volume 6, No. 3: e33. [2] . Conti, Body, Personal, and Local Wireless Adhoc Networks, Chapter 1 in Handbook of Adhoc Networks, CRC Press, New York, 2003 [3] Wireless Ethernet Standards Development: http://www.ieee802.org/11/ [4] Bluetooth Technology Specification: https://www.bluetooth.org/spec/ [5] Internet Engineering Task Force (IETF) Forum: http://www.ietf.org/ [6] D.F. Ferraiolo, J. Barkley, D.R. Kuhn, "A Role Based Access Control Model and Reference Implementation within a Corporate Intranet", ACM Transactions on Information Systems Security, Volume 1, Number 2, February 1999. [7] Dan C. Marinescu, Internet-Based Workflow Management: Toward a Semantic Web, ISBN: 0-471-43962-2, Wiley Publishers, April 2002. [8] D. Barbara, “Mobile Computing and Databases – A survey”, IEEE Transactions on Knowledge and Data Engineering, Vol. 11, No. 1, January/February 1999. [9] X. Yang, A. Bouguettaya, B. Medjahed, H. Long, and W. He, “Organizing and Accessing Web Services on Air”, IEEE Transactions on Systems, Man, and Cybernetics, Vol. 33, No. 6, November, 2003. [10] S. Gadiraju, and V. Kumar, “Recovery in the Mobile Wireless Environment Using Mobile Agents”, IEEE Transactions on Mobile Computing, Vol. 3, No. 2, April-June, 2004. [11] V. Kumar, N. Prabhu, M. Dunham, A. Seydim, “TCOT- A Timeout-Based Mobile Transaction Commitment Protocol”, IEEE Transactions on Computers, pp. 1212-1218, October 2002. [12] S. Lee, C. Hwang, and M. Kitsuregawa, “Using Predeclaration for Efficient Read-only Transaction Processing in Wireless Data Broadcast”, IEEE Transactions on Knowledge and Data Engineering, Vol. 15, No. 6, pp. 1579-1583, November/December 2003. [13] W. Peng, and M. Chen, “Design and Performance Studies of an Adaptive Cache retrieval Scheme in a Mobile Computing Environment”, IEEE Transactions on Mobile Computing, Vol. 4, No. 1, pp. 29-40, January/February 2005. [14] C. Ramaswamy and R. Sandhu, “Role Based Access Control Features in Commercial Database Management Systems”, Proceedings of 21st NIST-NCSC National Conference on Information Systems Security, 1998 [15] Q. Memon, A. Abdulhameed, “Dynamic Analysis of Role Based Workflows in Wireless Adhoc Networks”, Proceedings of World Symposium on Systemics, Cybernetics, and Informatics, Vol. 2, 2005, USA, pp. 95-100. [16] S. Osborn, R. Sandhu and Q. Munawer. “Configuring Role Based Access Control to Enforce Mandatory and Discretionary Access Control Policies.” ACM Trans. on Information and System Security, Volume 3, Number 2, May 2000, pages 85-106.

Higher Layer

User Management

Policies Roles & Rules

Credentials

Protocol Management

Event Service

Lower Layer Figure 3: The Acess Control Framework for Roles

2.5 Database:

Roles essentially partition database information into access contexts. Methods associated with a database object, also partition the object interface to provide windowed access to object information. By specifying that all database information is held in database objects and authorizing methods to roles, we achieve object interface distribution across roles. For processing in the commercial world we can design objects and distribute their associated methods to different roles. By authorizing different users to the different roles, we can enforce both the order of execution on the objects and separation of duty constraints on method execution. Our finding is that the products discussed in [14] provide a sound basis for implementing the basic features of RBAC, although there are significant differences but Sybase is the only one to directly support mutual exclusion of roles. Because of space limitations in mobile devices (like laptops etc.) the data is proposed to be in a single database residing in Coordinator. This is in addition to access control framework running on the coordinator. In case of PDA’s or similar devices, the database is proposed to be at the central server, where single or distributed databases can be placed.

3. Conclusions

The overhead required on network devices is role based framework and execution of access control algorithm. In

1166