- Email: [email protected]
Design and implementation of a fine-grained menu control processor for web-based information systems
Future Generation Computer Systems 19 (2003) 1105–1119
Design and implementation of a fine-grained menu control processor for web-based information systems Eric Jui-Lin Lu∗ , Rai-Fu Chen Department of Information Management, Chaoyang University of Technology, 168 Gifeng E. Rd., Wufeng, Taichung 413, Taiwan, ROC Received 22 August 2002; received in revised form 15 March 2003; accepted 17 March 2003
Abstract Web-based information systems (WISs) have become mainstream systems on the Internet and are widely deployed by enterprises worldwide. Although it is extremely important to secure access to WISs, the development of access control for WISs is still in its infancy stage. In addition, existing access control models for web applications are not suitable for WISs. In this paper, we proposed an access control model, called X-Menu, for WISs. Also, a prototype had been designed and implemented. The proposed model provides fine-grained control up to the element level of documents and is flexible and secured. The maintenance cost of the proposed model is low, and the proposed model can prevent users from performing any unauthorized task. © 2003 Elsevier B.V. All rights reserved. Keywords: WIS; Access control; XML; Fine-grained control
1. Introduction Due to the rapid proliferation of the Internet and the “friendliness” of the web interface, web-based information systems (WISs) have been widely deployed by enterprises to accomplish business tasks [21]. WISs are information systems that put emphasis on the interactions between users and backend systems and allow users to use the unique browser interface to access the backend systems anytime and anywhere [14,16]. In contrast to conventional web sites, WISs consist of inter-linked web pages that enable users to process business data interactively [20]. A click on a hyperlink is generally to invoke a server-side program written in languages such as Active Server Page (ASP), Java Server Page (JSP), Java, etc. ∗ Corresponding author. Tel.: +886-4-23323000x4285; fax: +886-4-23742337. E-mail address: [email protected] (E.J.-L. Lu).
Almost all WISs can be structured as a tree. Fig. 1 depicts an example WIS hierarchy. Each non-leaf node represents menu items that are shown either on a single web page (for example, the web page for the Node0 may contain four buttons and each button links to a program), or as a pull-down menu with sub-menus. (For example, for the Node0, it may consist of four pull-down menus. For “Personnel Dept”, there are three sub-menus as shown in Fig. 2.) A leaf node is usually a web page (such as Update.html) that consists of a hyperlink and form components such as textfields and checkboxes. The form components allow users to enter business data, and clicking on the hyperlink invokes a program to accomplish a business task. A path from the root node to a leaf node is called a navigation path. For example, Personnel Dept → Personal Data → Add → Add.html is a navigation path. Note that, if Add.html does not exist, this navigation path is meaningless in the WIS because no task can be accomplished.
0167-739X/$ – see front matter © 2003 Elsevier B.V. All rights reserved. doi:10.1016/S0167-739X(03)00108-0
1106
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 1. An example of WIS hierarchy.
Fig. 2. An example of WIS hierarchy represented as pull-down menus.
Although WISs have become the mainstream information systems used on the Internet, they have two serious limitations. The first limitation lies in the HTMLs innate design philosophy of the mixture of content and layout. For example, although the Node5 of Fig. 1 includes Add, Update, Query, and Delete functions, different users may have different access privileges (or different views) on the node. User A is allowed to access all four functions, but user B is only allowed to access Add and Update functions. By using HTML, system developers must generate a different set of web pages for each individual user. Thus, the number of web pages created for a WIS will grow exponentially as the number of users increases, and the maintenance of these web pages will become very difficult for system developers. Additionally, whenever a node, say the Node5, is changed, system developers have to modify all corresponding views generated from the Node5. As WISs become large and complex, the burden on the maintaining these web pages can be huge. To overcome this drawback, the Extensible Markup Language (XML) was proposed in 1998.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Because the design of the XML uses the separation of content and layout philosophy, one can easily use XML to describe a node such as the Node5 and apply different stylesheets on the node to generate different views for each individual user. Therefore, the maintenance cost of web sites can be reduced significantly. It is believed that the XML will become the major language for the development of WISs in the future. The second limitation is that the development of security models for WISs is still in its infancy stage [9,15]. Generally speaking, most of the existing access control mechanisms implemented for web applications can be classified into two major categories—role-based access control (RBAC) models [13,17,22] and the hypertext-based authorization models [5,7,10,11,18]. One of the core components of RBAC models is roles that represent different organizational responsibilities and functions. The use of the roles can simplify the task of authorization administration by organizing related access privileges to a role and assign users to the role. Later, if a user is promoted to a new position in the organization, the user can simply be assigned to a new role and removed from the old one. In addition, RBAC models support various security policies such as role hierarchies and constraint. Traditionally, the objects under control of RBAC models are either programs or documents. A role with access rights on an object can access the whole object but not portions of the object. This feature, however, seriously limits it applicability on WISs. For example, in the Node5 of Fig. 1, there are four functions and, thus, there are in the worst case 4! different views. In RBAC models, we need to develop 4! programs to generate these individual views and then associate roles to these programs. It would be a nightmare even to maintain a simple WIS like the one shown in Fig. 1 by using traditional RBAC models on WISs. The hypertext systems consist of inter-related web pages and the pages are connected through hyperlinks. In the hypertext-based authorization models [5,7,10,11,18], if a user is authorized to operate (viewing or authoring) either on a page or portions of it, the user will be presented with a view that the user is authorized to view or author. The hypertext-based authorization models put emphasis on the control of a document or portions of the document. For example, if an article is composed of four sections,
1107
the hypertext-based authorization models allow administrators to specify access rights for a user to view Section 1 and author Section 3. Although the hypertext-based authorization models provide finer control on a document, they do not support the finer control on programs which are responsible for the dynamic generation of web pages on WISs. Therefore, there is a strong need to develop an access control model for WISs that consist of a large amount of programs and web pages dynamically generated by the programs based on the user’s authorizations. In this paper, we propose an access control model, called X-Menu, for WISs. In X-Menu, after a user is successfully verified, a view based on the user’s authorization is generated. To provide finer granularity control to form components of views (for example, whether or not a component can be hidden, viewed, or updated), we use an XML document to describe the hierarchy of WISs. The schema of the XML document models the structure of WISs, expresses the relationships among objects in WISs, and defines various operations allowed on objects. Also, a prototype has been designed and implemented. For ensuring the security of user access, every user’s access request is under the control of the X-Menu processor and the user can only view or update a page that he is authorized to use. The proposed X-Menu model is flexible and secured and provides fine-grained control. The maintenance cost of X-Menu model is low. And the proposed model can prevent users from performing any unauthorized task. It is important to distinguish the major differences among RBAC models, hypertext-based authorization models, and the X-Menu model. In conventional RBAC models, a role with access rights on an object (a program or a document) can access the whole object but not portions of the object. Hypertext-based authorization models are mainly designed for browsing and authoring documents. Although hypertext-based authorization models allow access control at the element level of a document, their read and write operations are on the contents of the document. For the X-Menu model, the access control are divided into two parts. Based on a user’s privileges, the X-Menu processor first determines which programs the user is allowed to execute and which form components the user is allowed to operate. This part actually determines the views that the user is allowed to use. Then, in the second part, the invoked program processes business
1108
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
data on backend systems (for example, either update one or two fields) or displays the data properly (for example, which fields should be hidden or displayed) based on the user’s access rights. The rest of the paper is organized as follows. At first, we review RBAC and hypertext-based authorization models in Section 2. Then, we discuss the design issues of the X-Menu model in Section 3. The implementation details are discussed in Section 4. Then, we discuss and summarize the benefits of the proposed X-Menu model in Section 5. Finally, we conclude this paper in Section 6.
2. Literature review Currently, the development of access control for web applications are categorized into RBAC models and hypertext-based authorization models. 2.1. RBAC model Three major access control models used in traditional operation systems or database management systems are discretionary access control (DAC), mandatory access control (MAC), and RBAC models [3,19]. Among them, RBACs models are believed to be the best access control models for web applications [15]. In traditional access control models, the access control policy, called authorization, specifies what user (or subject) can access an object under what access mode. Because there is a direct link between a subject and every object to which the subject is authorized, the administration cost is high when the user’s privileges are modified frequently. The core component of RBAC model are roles which represent organizational responsibilities and functions. In RBAC models, by associating roles with subjects, it can effectively separate the strong links between subjects and objects and, thus, significantly decrease the authorization administration cost. For example, if a user is promoted to a new position in the organization, the user can simply be assigned to a new role and removed from the old one. Additionally, RBAC models support various security policies based on the role characteristic such as role hierarchies, separation of duty, and the limits on the number of users that can be authorized for a role.
In the web environment, access control is usually enforced by web servers. For example, the Apache Web server grants (or denies) users and hosts (or IPs) access through access control list described in a configuration file (access.conf) and constrains files and directories access using another configuration file (httpd.conf). Ferraiolo et al. [13] proposed and implemented a general RBAC system called RBAC/web. The RBAC/web consists of a web server to enforce various RBAC policies and provides administration tools for the authorization management. Although the RBAC/web provides an effective resource management mechanism based on RBAC models, however, it is not an ideal solution for access control on WISs. This is because a role can access a whole object, but not portions of the object. For example, in the Node5 of Fig. 1, there are four functions and, thus, there are in the worst case 4! different views. Therefore, in RBAC models, system developers need to develop 4! programs to generate these individual views and then associate roles to these programs. It would be a nightmare even to maintain a simple WIS like the one shown in Fig. 1 by directly using RBAC models on WISs. 2.2. Hypertext-based authorization models The hypertext systems [7,18] consist of inter-related documents connected by hyperlinks and allow users to view or author the documents based on their access rights. With the widespread adoption of XML documents in the hypertext systems, many hypertext-based authorization models based on XML were proposed [4–6,9–11]. Due to the richness of XML structure, these models support the following features: 1. Authorization levels: Hypertext-based authorization models provide schema- and document-level authorizations with the granularity of XML elements and attributes. If an authorization is specified for an XML schema, then all XML documents complying with the schema are having the same authorization. As for document-level, the authorization is only valid to a specific document. In practice, the schema authorization is used to define enterprise-wide access control policies, while the document-level authorization is used to provide a more detailed control on a specific document.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
2. Authorization signs: Authorizations can be granted (positive) or denied (negative) to access the XML documents and elements. A resolution policy is required to resolve conflicts when both negative and positive authorizations are specified on one object. It is often resolved by the policy of denial take precedence and, thus, the negative authorization will override the positive authorization. 3. Controlled propagation: The controlled propagation is used to control what propagation option an authorization can be applied to parent or child elements of a specific element. The propagation option is either no propagation, propagation up, or propagation down. “No propagation” means the authorization cannot propagate to other objects except for the objects itself. “Propagation down” and “propagation up” mean an authorization applied to a node also applies to its child nodes and parent nodes, respectively. 4. Authorization strengths: The authorization strengths state what authorization level has higher priority. In general, document-level authorizations take higher precedence over schema-level ones. The authorization strength can be defined through the specification of other authorizations to make the schema-level authorizations take precedence over document-level ones. Although existing hypertext-based authorization models provide viable mechanisms for various granularity level control on XML documents, it is a good
1109
solution for distributed document authoring systems and not quite suited for WISs. As stated earlier, WISs consist of programs and web pages dynamically generated by the programs. An access control model for WISs should be able to, based on a user’s authorizations, determine which programs can be performed as well as which form components of a web page can be viewed or updated. Additionally, the “behavior” of the invoked programs (for example, update one or two fields of a table) is partially determined by the user’s authorizations.
3. The design of X-Menu processor To perform functions provided by a WIS, a user of the WIS has to log on the system first. And then, the WIS will generate a view that the user is authorized to operate based on the user’s privileges. To accomplish the above tasks, it is required to know “the user’s information” such as username and password, “WIS hierarchy” which represents the structure of a WIS, and “authorization rules” which specify which user is authorized to view or update which documents, or elements, or attributes. These information are described in three separated configuration files. A conceptual access control model for WISs is shown in Fig. 3 and the model consists of four major components including web clients, a web server, an X-Menu processor, and backend systems. For ensuring the access security on WISs, each user’s request has to be evaluated by
Fig. 3. A conceptual access control model for WISs.
1110
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
the X-Menu processor. The evaluations are based on the privileges of the individual user’s authorizations which is a subset of the authorization rules. The details of the three configuration files are described as follows. 3.1. WIS hierarchy Because (1) every WIS in general has a hierarchical structure, (2) each non-leaf node in WIS hierarchy can be seen as a menu or a set of menus, (3) each leaf node is a web page with form components so that users can input or update business data, (4) we need access control up to the element level of web pages so that either a form component can be hidden or displayed or the value of form components such as “textfield” can be updated, and (5) the content and layout of the leaf node is separated, XML is used to describe the WIS hierarchy. Additionally, since the schema of WIS hierarchy does not require complex data types, and since we like to keep the schema as simple as possible, we choose DTD to describe the schema. Fig. 4 is the menu schema called Menu.dtd. In the schema, the Menus element is the root element and is composed of at least one menu. A menu can be constructed by other menus or elements. If a menu is a leaf node of a WIS, it contains only elements and the elements may contain sub-elements. For example, a group element such as SELECT contains other OPTION elements. A Menu element has four attributes—Id, Label, Level, and Prog. The value of the Id attribute is an unique identifier of the menu. The Label attribute is used to label the menu. The Level attribute represents the menu position, and the value of the Level attribute can be obtained auto-
matically based on the hierarchy of the example WIS. For example, if a menu is the second menu of the first child node of the root menu in the hierarchy of WIS, the value of the Level attribute is marked as “1-2”. The value of the Prog attribute represents the URL of a server-side program that is to be invoked when the menu is selected. An Element element consists of four attributes—Id, Label, Type, and Value. The Id and Label attributes are the unique identifier and the label of the element, respectively. Both Menu and Element elements have a unique ID attribute to indicate that they are unique in the WIS. The value of the ID attribute can be generated by using the OID generation algorithm [2]. Through the definition of the unique ID, it makes complex navigation possible. For example, a leaf node of a navigation path can link to any other node in the WIS hierarchy. The Value attribute is to give extra information for the elements of types BUTTON and OPTION. Because the element of type BUTTON represents a hyperlink to a server-side program, the URL of the program is defined in the Value attribute. The value of the Value attribute for an element of type OPTION is to indicate the default choice. For other types of elements, this attribute is optional. Because HTML supports various form components such as TEXT, LABEL, OPTION, etc., these components must be expressed in the menu schema. In the schema, we use the Type attribute to represent the HTML form components, and the acceptable attribute values of Types include GROUP, LABEL, SELECT, OPTION, RADIO, CHECKBOX, BUTTON, and TEXT. These values of attribute Type are chosen so that developers who are familiar with HTML can design the WIS hierarchy easily without remembering various
Fig. 4. Menu schema.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
syntax. The LABEL is used for labeling HTML form components. The SELECT and OPTION types are identical to the SELECT and OPTION elements of the HTML form components, respectively. The CHECKBOX, RADIO, and TEXT types are the same as the CHECKBOX, RADIO, and TEXT types, respectively, of INPUT element of the HTML form components. The BUTTON type is identical to the submit element of the HTML form components. If an element is of type GROUP, it can include other sub-elements. For example, an element of type GROUP can contain an element of type LABEL and several elements of type CHECKBOX (which allows users to check multiple boxes at a time), or an element of type LABEL and several elements of type RADIO (which allows users to select one and only one radio button at a time). In Fig. 5, it is an example instance of Menu.dtd of the example WIS. In the example, the WIS includes four systems for Personnel, Accounting, Manufacturing, and Administration departments. The Personnel Dept contains four menus—Reward/Penalty, Personal Data, and Regulation. In the Personal Data menu, it consists of Add, Update, Query, and Delete menus. In the interest of space, we only show partial information of the Update menu. This Update menu is a leaf node which consists of various elements and has one and only one element of type BUTTON. In line 25, the value of the Value attribute is: http://localhost/servlets/UpdateProcess which is the URL of the server-side program.
1111
and department indicate the group and department that a user belongs to, respectively. A user can belong to more than one group. The title represents a position in the organization that a user holds. By deploying credentials, we can specify an authorization rule to a set of users rather than an individual user. Therefore, the complexity of authorization management can be simplified significantly due to the reduction of authorization rules. The schema for user information is shown in Fig. 6. 3.3. Authorization rules
3.2. User information
Authorization rules specify who can access which object under which mode. Therefore, an authorization rule consists of three major parts, namely subject, object, and mode. Also, we have to consider security policies [4–6,9–11] such as authorization signs, authorization levels, authorization strengths, and controlled propagation mentioned in the previous section. In the current implementation of X-Menu, we assume there is only one WIS for a web server. Therefore, there is only one instance of Menu.dtd and thus schema-level authorization is not required. As a result, authorization signs and controlled propagation are not considered in the authorization rules. However, multiple WISs in one web server or distributed in different web servers managed in a federated manner may be implemented in the future. The schema we designed for the authorization rules is shown in Fig. 7(a) and an example instance complying the schema is shown in Fig. 7(b). In the schema, an authorization rule consists of six parts: cred-expr, target, path, priv, type, and prop:
All authentication mechanisms require user information to verify user’s identity. The required user’s information includes username and password. In addition, to provide a flexible authorization policy, we adopt credential-based security policies [5] whose authorization are based on user’s properties. For example, if a user’s age is greater than 18, the user can then watch rated programs. The age becomes the credential property of the user. The credential properties included in the user information are id, username, group, department, and title. The id represents a unique identifier of an employee, and the username represents the account name. The group
1. cred-expr: It represents the subject part of an authorization rule. In the design of the proposed model, we deployed credential-based security policies to specify what user properties can be applied to the authorization rules. As shown in Fig. 7(b)(1), the example authorization rule is for all users whose username is “Bob”. In addition to username, we also allow user properties such as id, department, group, and title to be applied to authorization rules. For example, if the value of the cred-expr is “//Person[group = “Administrators”]”, the specified subjects are all users whose group is “Administrators”.
1112
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 5. An example instance of Menu.dtd.
2. target and path: Both target and path jointly identify the object of an authorization rule. The target specifies the URL of the target document, and the path identifies the path to locate a node
or an element in the target document. The path is described in XPath expressions. Through the specification of XPath expression, the authorization can be applied to a whole document, ele-
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
1113
Fig. 6. User credential schema.
ments (with or without sub-elements), or even attributes. 3. type and priv: Both type and priv jointly specify the mode of an authorization rule. The access to an object (or a set of objects) can be granted or denied by using the type attribute. In cases where authorizations on an object (or a set of objects) are conflicting, the access to the object is denied by default. The priv attribute indicates the privileges that the authorized subject on an object. In other words, the priv attribute specifies which operation is allowed to perform on the object. The acceptable values for the priv attribute are VIEW and UPDATE. The UPDATE indicates the subject is authorized to enter a new value for (or update) a specified object, while the VIEW only allows the subject to view the value of the specified object. The VIEW or UPDATE value can be specified on the elements of leaf nodes. For non-leaf nodes, the VIEW or UPDATE is ignored. If the type value is defined as DENIED, the specification of the priv is ignored, the specified object will not be displayed on screen, and thus the specified subject (or subjects) cannot operate (view or update) the specified object. When both VIEW and UPDATE are
authorized on the same object, the VIEW privilege overrides the UPDATE privilege to conform to the principle of least privileges [13]. In addition, the authorization rules for the lower level nodes take precedence of the authorization rules for the higher level nodes in the WIS hierarchy. 4. prop: It represents the propagation policy for the authorization rule. As shown in Fig. 1, the Personnel Dept → Personal Data → Add → Add.html is a navigation path. Due to the hierarchy of WISs, it makes no sense to authorize a user to be able to view Add.html without allowing the user to view Personnel Dept, Personal Data, and Add. Thus, in the schema, the value of the prop attribute is fixed as “CASCADE” to indicate that, whenever the access to a node is granted, the authorization will be automatically applied recursively to all its parent nodes. 3.4. Menu generation process WISs can be expressed as a set of inter-related menus. Each menu represents a view that a user is authorized to use. And a click on a menu button will
Fig. 7. (a) The schema for authorization rules and (b) an example authorization rules complying to (a).
1114
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 8. Menu generation process.
trigger a program to generate a menu or a web page that contains HTML form components which allows users to interact with backend systems. The above process is depicted in Fig. 8. The process can be divided into menu generation stage and view generation stage. 1. Menu generation stage: It is assumed that an individual user’s identification is verified successfully and the communication channel between the client and the web server is secured. The menu generator uses the configuration files for the WIS hierarchy and the authorization rules to generate a menu structure for the user. The newly generated menu structure is also described in XML. 2. View generation stage: After user’s menu structure is obtained, it is processed by the view generator to generate a view. The view can be expressed in HTML, WML, or any other formats that can be processed by XSLT. Note that, if WML pages are generated, the proposed model can also be used for information retrieval using cellular phones. Also, as long as the schemata for the WIS hierarchy, user information, and authorization rules remain unchanged, all XSLT files and two generators do not have to be re-written for other WISs.
documents into menus (in XML) and views (in HTML or WML) as shown in Fig. 8, we deployed XSLT for the transformations. Apache’s Xalan is used for processing XML and XSLT files. Due to the hierarchical structure of WISs, it is likely that a user is only authorized to the nodes A, B, F, and L as shown in Fig. 9. Therefore, the user has to navigate from node A, node B, node F, and then to node L to perform a specific task. This is tedious. For convenience, in our implementation, node L will be displayed to the user after logging in. Supposed that Bob is a manager of a company and has access to almost all functions of the example WIS. Because the salary of an employee is a sensitive data, it can only be updated by a privileged user such as Bob. For separation of duty, Bob does not enter data for new employees, but he is authorized to view all user’s information. The authorization rules for Bob are shown in Fig. 7(b). In Fig. 7(b)(1), because the path of the authorization rule is “/Menus”, Bob is authorized to access all functions of the example WIS, and this
4. Implementation To verify the effectiveness of the proposed model, a prototype was developed. Also, to ease the maintenance burden, administrative tools were implemented to manage the user information, authorization rules, and WIS hierarchy. For portability, we chose Java to develop the prototype. Because the user information, authorization rules, and WIS hierarchy are all encoded in XML; and because we need to transform the XML
Fig. 9. An example of reduced navigation path.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
results in the view as shown in Fig. 11(a) after he logs in. Fig. 7(b)(2) forbids Bob to enter data for new employees whose menu id is “M-0000-000004”. Additionally, Fig. 7(b)(4) indicates that Bob is authorized to update the salary field, whose id is “E-0000-000132”. As for other employee information, Bob is authorized to view which is shown in Fig. 7(3). The last two rules determine the view on the Update menu as shown in Fig. 12(a). Moreover, since Bob is allowed to update an employee’s salary, a label and a textfield for entering salary are shown in Fig. 12(a). Tom is a staff of the personnel department of the company and allowed to enter data for new employees except for the salary field. Tom also has the privileges to update and query all the employees’ data except for the salary filed. The authorization rules for Tom are shown in Fig. 10. As shown in Fig. 10(a) and (c)–(e), Tom is not authorized to access the systems developed for accounting, manufacturing, and administration departments whose menu IDs are “M-0000-000009”, “M-0000-000019” and “M-0000-000021”, respectively. Tom is not authorized to view the salary field of all employees and,
1115
thus, Fig. 10(f)–(h) prevent him from viewing it in the Add, Update, and Query menus. The element IDs of the salary fields in the Add, Update, and Query menus are “E-0000-000013”, “E-0000-000132”, and “E-0000-000152”, respectively. Fig. 11(b) is the view that is generated based on Tom’s privileges after he logs in. Because Tom is not authorized to use any function designed for the accounting, manufacturing, and administration departments, there are no “Accounting Dept”, “Manufacturing Dept”, and “Administration Dept” buttons as shown in Fig. 11(b). This feature prevents users from performing tasks that they are not allowed and, thus, decreases errors and system’s resources. Furthermore, Tom is authorized to update employee’s data except for the salary field. Therefore, Tom’s view on the Update menu is shown as Fig. 12(b). Without the salary field displayed in the page, errors and unauthorized actions can be avoided. There is one important feature that is hidden in Fig. 12. The “Submit” buttons in both Bob’s and Tom’s views are pointed to one identical program whose URL is: http://localhost/servlets/UpdateProcess
Fig. 10. Tom’s authorizations.
1116
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 11. (a) Bob’s and (b) Tom’s views on the example WIS.
as defined in line 25 of Fig. 5. However, the “behavior” of the program is partially dependent on who invokes it. On one hand, when Bob clicks on the “Submit” button, only the salary field is updated. On the other hand, when Tom clicks on the “Submit” button, all values of the Address, Department, and Experience
fields are updated. The number of fields to be updated is determined by the authorization rules of the user. Because Tom is authorized to enter data for new employees and query employee’s information except for the salary field, the Add and Query menus that Tom are authorized to use are shown in Fig. 13(a) and (b),
Fig. 12. (a) Bob’s and (b) Tom’s views on the Update menu.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
1117
Fig. 13. Tom’s view on the (a) Add and (b) Query menus.
respectively. In the Query function, Tom is authorized to query the values of the Username, Address, Department, and Experience fields. Also, he can selectively choose which fields he want to see using the “checkbox” options as shown in Fig. 13(b). Again, the number of fields to be displayed is determined by the authorization rules of the user.
5. Discussions We proposed an access control model, called XMenu, as well as design and implement a prototype for an example WIS. Throughout the development, we observed the following benefits of the proposed model: 1. Fine-grained control: The X-Menu model uses XML to model the user information, WIS hierarchy, and authorization rules. Therefore, we can specify authorizations on a whole document, elements (with or without sub-elements), and attributes. 2. Flexibility: The X-Menu processor deploys credential-based security policies. Based on user properties, we can specify an authorization rule to a user’s property such as group and department. Therefore, the proposed model provides flexible
authorization specifications, and the cost for authorization management is reduced. 3. Security: It is important to ensure the security of data transmitted over Internet. Also, many existing WISs use username and password to authenticate users. By incorporating the proposed model with Secure Socket Layer (SSL) services on web servers, a secure environment is ensured. 4. Low maintenance cost: In the proposed model, all information are expressed in XML. Due to the XML design principle of the separation of content and layout, one document can be applied to different stylesheets to generate different web pages. Whenever the content of the document is modified, nothing has to be done by developers. Also, as stated earlier, the number of programs and XML documents that need to be maintained in the proposed model is much smaller than the number of programs in RBAC models. For example, in considering the first two levels of the example WIS in Fig. 1, we need to maintain, in the worst case, 8 × (3! + 2! + 2! + 2!) programs by using RBAC models. (To reach the Node1, “Personnel Dept” in the Node0 has to be selected. There are eight possible menu combinations that include “Personnel Dept”. In the Node1, there are 3! possible menu combinations. Thus, we have a total of 8×3!
1118
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
menu combinations. Similarly, the possible menu combinations for the Node2, Node3, and Node4 are all 8 × 2!.) While only (4 + 3 + 2 + 2 + 2) programs and five XML documents (including two XSLT stylesheets and three configuration files) are required to be maintained in the X-Menu model. 5. Error prevention: Practically, in the design of information systems, we like to reduce the chances that errors may occur and avoid any unauthorized action to endanger systems. Therefore, for any function that a user is not authorized to perform, the function should not be displayed in front of the user. We deployed such design principle in the proposed model, and thus any function that the user is not authorized to perform will be hidden from the user to prevent errors. 6. Personalization: In contemporary enterprises, personalization or customization is very important in keeping good relationships with customers or suppliers. By adapting the X-Menu model, we can easily provide personalized web pages for users based on their preferences.
6. Conclusions WISs have become mainstream systems on the Internet. However, the development of access control for WISs is still in its infancy stage. Although there exists many access control models for web applications, they are not suitable for WISs. In this paper, we proposed an access control model for WISs. Also, a prototype had been designed and implemented. The proposed model provides fine-grained control up to the element level of web pages and is flexible and secured. Any unauthorized action is prevented from performing by users. Because the number of programs and XML documents that need to be maintained in the proposed model is much smaller than the number of programs in RBAC models, the maintenance cost is low. To make maintenance even easier, some utility programs can be developed for the management of XML documents for describing WIS hierarchy, user information, and authorization rules. The maintenance work can be further reduced if native XML databases [8] such as Tamino [1] and eXcelon [12] are employed.
In the current design of the proposed model, the authorization specification is based on user’s properties and, therefore, can be further extended to incorporate the concept of role to provide a better control mechanism for WISs in the future. Also, in our model, we assume that there is only one WIS for a web server. We wish to extend the proposed control model to the cases of multiple WISs in one web server or distributed in different web servers managed in a federated manner in the future.
Acknowledgements This research was partially supported by the National Science Council, Taiwan, ROC, under contract number NSC91-2213-E-324-015.
References [1] Software AG, Tamino XML server. http://www.softwareag. com/tamino/. [2] S.W. Ambler, Mapping objects to relational databases, Ronin International, 2000. http://www.AmbySoft.com/ mappingObjects.pdf. [3] E. Bertina, Data security, Data Knowledge Eng. 25 (1998) 199–216. [4] E. Bertino, B. Carminati, E. Ferrari, XML security, Inform. Security Tech. Rep. 6 (2) (2001) 44–58. [5] E. Bertino, S. Castano, E. Ferrari, Securing XML documents with Author-X, IEEE Internet Comput. 5 (3) (2001) 21–31. [6] E. Bertino, S. Castano, E. Ferrari, M. Mesiti, Specifying and enforcing of access control policies for XML document sources, World Wide Web J. 3 (3) (2000) 1–25. [7] E. Bertino, E. Pagani, G.P. Rossi, P. Samarati, Protecting information on the web, Commun. ACM 43 (3) (2000) 189– 199. [8] R. Bourret, XML and databases. http://www.rpbourret.com/ xml/XMLAndDatabases.htm. [9] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, Design and implementation of an access control processor for XML documents, Comput. Networks 33 (2000) 59–75. [10] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, A fine-grained access control system for XML documents, ACM Trans. Inform. Syst. Security 5 (2002) 169– 202. [11] E. Damiani, P. Samarati, S. De Capitani di Vimercati, S. Paraboschi, Controlling access to XML documents, IEEE Internet Comput. 5 (6) (2001) 18–28. [12] eXcelon Corporation, eXtensible Information Server (XIS). http://www.odi.com/products/xis/.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119 [13] D.F. Ferraiolo, J.F. Barkley, D. Richard Kuhn, A role-based access control model and reference implementation within a corporate Intranet, ACM Trans. Inform. Syst. Security 2 (1) (1999) 34–64. [14] T. Isakowitz, M. Bieber, F. Vitali, Web information systems, Commun. ACM 41 (7) (1998) 78–80. [15] J.B.D. Joshi, W.G. Aref, A. Ghafoor, E.H. Spafford, Security models for web-based applications, Commun. ACM 44 (2) (2001) 38–44. [16] H. Maurer, Modern WISs, Commun. ACM 41 (7) (1998) 114–115. [17] J.S. Park, R. Sandhu, Role-based access control on the web, ACM Trans. Inform. Syst. Security 4 (1) (2001) 37–71.
1119
[18] P. Samarati, E. Bertino, S. Jajodia, An authorization model for a distributed hypertext system, IEEE Trans. Knowledge Data Eng. 8 (4) (1996) 555–562. [19] R.S. Sandhu, P. Samarati, Access control: principles and practice, IEEE Commun. Mag. 32 (9) (1994) 40–48. [20] K. Takahashi, Metalevel links: more power to your links, Commun. ACM 41 (7) (1998) 103–105. [21] K. Takahashi, E. Liang, Analysis and design of web-based information systems, Comput. Networks ISDN Syst. 29 (1997) 1167–1180. [22] Z. Tari, S.-W. Chan, A role-based access control for Intranet security, IEEE Internet Comput. 1 (5) (1997) 24–34.
Design and implementation of a fine-grained menu control processor for web-based information systems Eric Jui-Lin Lu∗ , Rai-Fu Chen Department of Information Management, Chaoyang University of Technology, 168 Gifeng E. Rd., Wufeng, Taichung 413, Taiwan, ROC Received 22 August 2002; received in revised form 15 March 2003; accepted 17 March 2003
Abstract Web-based information systems (WISs) have become mainstream systems on the Internet and are widely deployed by enterprises worldwide. Although it is extremely important to secure access to WISs, the development of access control for WISs is still in its infancy stage. In addition, existing access control models for web applications are not suitable for WISs. In this paper, we proposed an access control model, called X-Menu, for WISs. Also, a prototype had been designed and implemented. The proposed model provides fine-grained control up to the element level of documents and is flexible and secured. The maintenance cost of the proposed model is low, and the proposed model can prevent users from performing any unauthorized task. © 2003 Elsevier B.V. All rights reserved. Keywords: WIS; Access control; XML; Fine-grained control
1. Introduction Due to the rapid proliferation of the Internet and the “friendliness” of the web interface, web-based information systems (WISs) have been widely deployed by enterprises to accomplish business tasks [21]. WISs are information systems that put emphasis on the interactions between users and backend systems and allow users to use the unique browser interface to access the backend systems anytime and anywhere [14,16]. In contrast to conventional web sites, WISs consist of inter-linked web pages that enable users to process business data interactively [20]. A click on a hyperlink is generally to invoke a server-side program written in languages such as Active Server Page (ASP), Java Server Page (JSP), Java, etc. ∗ Corresponding author. Tel.: +886-4-23323000x4285; fax: +886-4-23742337. E-mail address: [email protected] (E.J.-L. Lu).
Almost all WISs can be structured as a tree. Fig. 1 depicts an example WIS hierarchy. Each non-leaf node represents menu items that are shown either on a single web page (for example, the web page for the Node0 may contain four buttons and each button links to a program), or as a pull-down menu with sub-menus. (For example, for the Node0, it may consist of four pull-down menus. For “Personnel Dept”, there are three sub-menus as shown in Fig. 2.) A leaf node is usually a web page (such as Update.html) that consists of a hyperlink and form components such as textfields and checkboxes. The form components allow users to enter business data, and clicking on the hyperlink invokes a program to accomplish a business task. A path from the root node to a leaf node is called a navigation path. For example, Personnel Dept → Personal Data → Add → Add.html is a navigation path. Note that, if Add.html does not exist, this navigation path is meaningless in the WIS because no task can be accomplished.
0167-739X/$ – see front matter © 2003 Elsevier B.V. All rights reserved. doi:10.1016/S0167-739X(03)00108-0
1106
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 1. An example of WIS hierarchy.
Fig. 2. An example of WIS hierarchy represented as pull-down menus.
Although WISs have become the mainstream information systems used on the Internet, they have two serious limitations. The first limitation lies in the HTMLs innate design philosophy of the mixture of content and layout. For example, although the Node5 of Fig. 1 includes Add, Update, Query, and Delete functions, different users may have different access privileges (or different views) on the node. User A is allowed to access all four functions, but user B is only allowed to access Add and Update functions. By using HTML, system developers must generate a different set of web pages for each individual user. Thus, the number of web pages created for a WIS will grow exponentially as the number of users increases, and the maintenance of these web pages will become very difficult for system developers. Additionally, whenever a node, say the Node5, is changed, system developers have to modify all corresponding views generated from the Node5. As WISs become large and complex, the burden on the maintaining these web pages can be huge. To overcome this drawback, the Extensible Markup Language (XML) was proposed in 1998.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Because the design of the XML uses the separation of content and layout philosophy, one can easily use XML to describe a node such as the Node5 and apply different stylesheets on the node to generate different views for each individual user. Therefore, the maintenance cost of web sites can be reduced significantly. It is believed that the XML will become the major language for the development of WISs in the future. The second limitation is that the development of security models for WISs is still in its infancy stage [9,15]. Generally speaking, most of the existing access control mechanisms implemented for web applications can be classified into two major categories—role-based access control (RBAC) models [13,17,22] and the hypertext-based authorization models [5,7,10,11,18]. One of the core components of RBAC models is roles that represent different organizational responsibilities and functions. The use of the roles can simplify the task of authorization administration by organizing related access privileges to a role and assign users to the role. Later, if a user is promoted to a new position in the organization, the user can simply be assigned to a new role and removed from the old one. In addition, RBAC models support various security policies such as role hierarchies and constraint. Traditionally, the objects under control of RBAC models are either programs or documents. A role with access rights on an object can access the whole object but not portions of the object. This feature, however, seriously limits it applicability on WISs. For example, in the Node5 of Fig. 1, there are four functions and, thus, there are in the worst case 4! different views. In RBAC models, we need to develop 4! programs to generate these individual views and then associate roles to these programs. It would be a nightmare even to maintain a simple WIS like the one shown in Fig. 1 by using traditional RBAC models on WISs. The hypertext systems consist of inter-related web pages and the pages are connected through hyperlinks. In the hypertext-based authorization models [5,7,10,11,18], if a user is authorized to operate (viewing or authoring) either on a page or portions of it, the user will be presented with a view that the user is authorized to view or author. The hypertext-based authorization models put emphasis on the control of a document or portions of the document. For example, if an article is composed of four sections,
1107
the hypertext-based authorization models allow administrators to specify access rights for a user to view Section 1 and author Section 3. Although the hypertext-based authorization models provide finer control on a document, they do not support the finer control on programs which are responsible for the dynamic generation of web pages on WISs. Therefore, there is a strong need to develop an access control model for WISs that consist of a large amount of programs and web pages dynamically generated by the programs based on the user’s authorizations. In this paper, we propose an access control model, called X-Menu, for WISs. In X-Menu, after a user is successfully verified, a view based on the user’s authorization is generated. To provide finer granularity control to form components of views (for example, whether or not a component can be hidden, viewed, or updated), we use an XML document to describe the hierarchy of WISs. The schema of the XML document models the structure of WISs, expresses the relationships among objects in WISs, and defines various operations allowed on objects. Also, a prototype has been designed and implemented. For ensuring the security of user access, every user’s access request is under the control of the X-Menu processor and the user can only view or update a page that he is authorized to use. The proposed X-Menu model is flexible and secured and provides fine-grained control. The maintenance cost of X-Menu model is low. And the proposed model can prevent users from performing any unauthorized task. It is important to distinguish the major differences among RBAC models, hypertext-based authorization models, and the X-Menu model. In conventional RBAC models, a role with access rights on an object (a program or a document) can access the whole object but not portions of the object. Hypertext-based authorization models are mainly designed for browsing and authoring documents. Although hypertext-based authorization models allow access control at the element level of a document, their read and write operations are on the contents of the document. For the X-Menu model, the access control are divided into two parts. Based on a user’s privileges, the X-Menu processor first determines which programs the user is allowed to execute and which form components the user is allowed to operate. This part actually determines the views that the user is allowed to use. Then, in the second part, the invoked program processes business
1108
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
data on backend systems (for example, either update one or two fields) or displays the data properly (for example, which fields should be hidden or displayed) based on the user’s access rights. The rest of the paper is organized as follows. At first, we review RBAC and hypertext-based authorization models in Section 2. Then, we discuss the design issues of the X-Menu model in Section 3. The implementation details are discussed in Section 4. Then, we discuss and summarize the benefits of the proposed X-Menu model in Section 5. Finally, we conclude this paper in Section 6.
2. Literature review Currently, the development of access control for web applications are categorized into RBAC models and hypertext-based authorization models. 2.1. RBAC model Three major access control models used in traditional operation systems or database management systems are discretionary access control (DAC), mandatory access control (MAC), and RBAC models [3,19]. Among them, RBACs models are believed to be the best access control models for web applications [15]. In traditional access control models, the access control policy, called authorization, specifies what user (or subject) can access an object under what access mode. Because there is a direct link between a subject and every object to which the subject is authorized, the administration cost is high when the user’s privileges are modified frequently. The core component of RBAC model are roles which represent organizational responsibilities and functions. In RBAC models, by associating roles with subjects, it can effectively separate the strong links between subjects and objects and, thus, significantly decrease the authorization administration cost. For example, if a user is promoted to a new position in the organization, the user can simply be assigned to a new role and removed from the old one. Additionally, RBAC models support various security policies based on the role characteristic such as role hierarchies, separation of duty, and the limits on the number of users that can be authorized for a role.
In the web environment, access control is usually enforced by web servers. For example, the Apache Web server grants (or denies) users and hosts (or IPs) access through access control list described in a configuration file (access.conf) and constrains files and directories access using another configuration file (httpd.conf). Ferraiolo et al. [13] proposed and implemented a general RBAC system called RBAC/web. The RBAC/web consists of a web server to enforce various RBAC policies and provides administration tools for the authorization management. Although the RBAC/web provides an effective resource management mechanism based on RBAC models, however, it is not an ideal solution for access control on WISs. This is because a role can access a whole object, but not portions of the object. For example, in the Node5 of Fig. 1, there are four functions and, thus, there are in the worst case 4! different views. Therefore, in RBAC models, system developers need to develop 4! programs to generate these individual views and then associate roles to these programs. It would be a nightmare even to maintain a simple WIS like the one shown in Fig. 1 by directly using RBAC models on WISs. 2.2. Hypertext-based authorization models The hypertext systems [7,18] consist of inter-related documents connected by hyperlinks and allow users to view or author the documents based on their access rights. With the widespread adoption of XML documents in the hypertext systems, many hypertext-based authorization models based on XML were proposed [4–6,9–11]. Due to the richness of XML structure, these models support the following features: 1. Authorization levels: Hypertext-based authorization models provide schema- and document-level authorizations with the granularity of XML elements and attributes. If an authorization is specified for an XML schema, then all XML documents complying with the schema are having the same authorization. As for document-level, the authorization is only valid to a specific document. In practice, the schema authorization is used to define enterprise-wide access control policies, while the document-level authorization is used to provide a more detailed control on a specific document.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
2. Authorization signs: Authorizations can be granted (positive) or denied (negative) to access the XML documents and elements. A resolution policy is required to resolve conflicts when both negative and positive authorizations are specified on one object. It is often resolved by the policy of denial take precedence and, thus, the negative authorization will override the positive authorization. 3. Controlled propagation: The controlled propagation is used to control what propagation option an authorization can be applied to parent or child elements of a specific element. The propagation option is either no propagation, propagation up, or propagation down. “No propagation” means the authorization cannot propagate to other objects except for the objects itself. “Propagation down” and “propagation up” mean an authorization applied to a node also applies to its child nodes and parent nodes, respectively. 4. Authorization strengths: The authorization strengths state what authorization level has higher priority. In general, document-level authorizations take higher precedence over schema-level ones. The authorization strength can be defined through the specification of other authorizations to make the schema-level authorizations take precedence over document-level ones. Although existing hypertext-based authorization models provide viable mechanisms for various granularity level control on XML documents, it is a good
1109
solution for distributed document authoring systems and not quite suited for WISs. As stated earlier, WISs consist of programs and web pages dynamically generated by the programs. An access control model for WISs should be able to, based on a user’s authorizations, determine which programs can be performed as well as which form components of a web page can be viewed or updated. Additionally, the “behavior” of the invoked programs (for example, update one or two fields of a table) is partially determined by the user’s authorizations.
3. The design of X-Menu processor To perform functions provided by a WIS, a user of the WIS has to log on the system first. And then, the WIS will generate a view that the user is authorized to operate based on the user’s privileges. To accomplish the above tasks, it is required to know “the user’s information” such as username and password, “WIS hierarchy” which represents the structure of a WIS, and “authorization rules” which specify which user is authorized to view or update which documents, or elements, or attributes. These information are described in three separated configuration files. A conceptual access control model for WISs is shown in Fig. 3 and the model consists of four major components including web clients, a web server, an X-Menu processor, and backend systems. For ensuring the access security on WISs, each user’s request has to be evaluated by
Fig. 3. A conceptual access control model for WISs.
1110
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
the X-Menu processor. The evaluations are based on the privileges of the individual user’s authorizations which is a subset of the authorization rules. The details of the three configuration files are described as follows. 3.1. WIS hierarchy Because (1) every WIS in general has a hierarchical structure, (2) each non-leaf node in WIS hierarchy can be seen as a menu or a set of menus, (3) each leaf node is a web page with form components so that users can input or update business data, (4) we need access control up to the element level of web pages so that either a form component can be hidden or displayed or the value of form components such as “textfield” can be updated, and (5) the content and layout of the leaf node is separated, XML is used to describe the WIS hierarchy. Additionally, since the schema of WIS hierarchy does not require complex data types, and since we like to keep the schema as simple as possible, we choose DTD to describe the schema. Fig. 4 is the menu schema called Menu.dtd. In the schema, the Menus element is the root element and is composed of at least one menu. A menu can be constructed by other menus or elements. If a menu is a leaf node of a WIS, it contains only elements and the elements may contain sub-elements. For example, a group element such as SELECT contains other OPTION elements. A Menu element has four attributes—Id, Label, Level, and Prog. The value of the Id attribute is an unique identifier of the menu. The Label attribute is used to label the menu. The Level attribute represents the menu position, and the value of the Level attribute can be obtained auto-
matically based on the hierarchy of the example WIS. For example, if a menu is the second menu of the first child node of the root menu in the hierarchy of WIS, the value of the Level attribute is marked as “1-2”. The value of the Prog attribute represents the URL of a server-side program that is to be invoked when the menu is selected. An Element element consists of four attributes—Id, Label, Type, and Value. The Id and Label attributes are the unique identifier and the label of the element, respectively. Both Menu and Element elements have a unique ID attribute to indicate that they are unique in the WIS. The value of the ID attribute can be generated by using the OID generation algorithm [2]. Through the definition of the unique ID, it makes complex navigation possible. For example, a leaf node of a navigation path can link to any other node in the WIS hierarchy. The Value attribute is to give extra information for the elements of types BUTTON and OPTION. Because the element of type BUTTON represents a hyperlink to a server-side program, the URL of the program is defined in the Value attribute. The value of the Value attribute for an element of type OPTION is to indicate the default choice. For other types of elements, this attribute is optional. Because HTML supports various form components such as TEXT, LABEL, OPTION, etc., these components must be expressed in the menu schema. In the schema, we use the Type attribute to represent the HTML form components, and the acceptable attribute values of Types include GROUP, LABEL, SELECT, OPTION, RADIO, CHECKBOX, BUTTON, and TEXT. These values of attribute Type are chosen so that developers who are familiar with HTML can design the WIS hierarchy easily without remembering various
Fig. 4. Menu schema.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
syntax. The LABEL is used for labeling HTML form components. The SELECT and OPTION types are identical to the SELECT and OPTION elements of the HTML form components, respectively. The CHECKBOX, RADIO, and TEXT types are the same as the CHECKBOX, RADIO, and TEXT types, respectively, of INPUT element of the HTML form components. The BUTTON type is identical to the submit element of the HTML form components. If an element is of type GROUP, it can include other sub-elements. For example, an element of type GROUP can contain an element of type LABEL and several elements of type CHECKBOX (which allows users to check multiple boxes at a time), or an element of type LABEL and several elements of type RADIO (which allows users to select one and only one radio button at a time). In Fig. 5, it is an example instance of Menu.dtd of the example WIS. In the example, the WIS includes four systems for Personnel, Accounting, Manufacturing, and Administration departments. The Personnel Dept contains four menus—Reward/Penalty, Personal Data, and Regulation. In the Personal Data menu, it consists of Add, Update, Query, and Delete menus. In the interest of space, we only show partial information of the Update menu. This Update menu is a leaf node which consists of various elements and has one and only one element of type BUTTON. In line 25, the value of the Value attribute is: http://localhost/servlets/UpdateProcess which is the URL of the server-side program.
1111
and department indicate the group and department that a user belongs to, respectively. A user can belong to more than one group. The title represents a position in the organization that a user holds. By deploying credentials, we can specify an authorization rule to a set of users rather than an individual user. Therefore, the complexity of authorization management can be simplified significantly due to the reduction of authorization rules. The schema for user information is shown in Fig. 6. 3.3. Authorization rules
3.2. User information
Authorization rules specify who can access which object under which mode. Therefore, an authorization rule consists of three major parts, namely subject, object, and mode. Also, we have to consider security policies [4–6,9–11] such as authorization signs, authorization levels, authorization strengths, and controlled propagation mentioned in the previous section. In the current implementation of X-Menu, we assume there is only one WIS for a web server. Therefore, there is only one instance of Menu.dtd and thus schema-level authorization is not required. As a result, authorization signs and controlled propagation are not considered in the authorization rules. However, multiple WISs in one web server or distributed in different web servers managed in a federated manner may be implemented in the future. The schema we designed for the authorization rules is shown in Fig. 7(a) and an example instance complying the schema is shown in Fig. 7(b). In the schema, an authorization rule consists of six parts: cred-expr, target, path, priv, type, and prop:
All authentication mechanisms require user information to verify user’s identity. The required user’s information includes username and password. In addition, to provide a flexible authorization policy, we adopt credential-based security policies [5] whose authorization are based on user’s properties. For example, if a user’s age is greater than 18, the user can then watch rated programs. The age becomes the credential property of the user. The credential properties included in the user information are id, username, group, department, and title. The id represents a unique identifier of an employee, and the username represents the account name. The group
1. cred-expr: It represents the subject part of an authorization rule. In the design of the proposed model, we deployed credential-based security policies to specify what user properties can be applied to the authorization rules. As shown in Fig. 7(b)(1), the example authorization rule is for all users whose username is “Bob”. In addition to username, we also allow user properties such as id, department, group, and title to be applied to authorization rules. For example, if the value of the cred-expr is “//Person[group = “Administrators”]”, the specified subjects are all users whose group is “Administrators”.
1112
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 5. An example instance of Menu.dtd.
2. target and path: Both target and path jointly identify the object of an authorization rule. The target specifies the URL of the target document, and the path identifies the path to locate a node
or an element in the target document. The path is described in XPath expressions. Through the specification of XPath expression, the authorization can be applied to a whole document, ele-
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
1113
Fig. 6. User credential schema.
ments (with or without sub-elements), or even attributes. 3. type and priv: Both type and priv jointly specify the mode of an authorization rule. The access to an object (or a set of objects) can be granted or denied by using the type attribute. In cases where authorizations on an object (or a set of objects) are conflicting, the access to the object is denied by default. The priv attribute indicates the privileges that the authorized subject on an object. In other words, the priv attribute specifies which operation is allowed to perform on the object. The acceptable values for the priv attribute are VIEW and UPDATE. The UPDATE indicates the subject is authorized to enter a new value for (or update) a specified object, while the VIEW only allows the subject to view the value of the specified object. The VIEW or UPDATE value can be specified on the elements of leaf nodes. For non-leaf nodes, the VIEW or UPDATE is ignored. If the type value is defined as DENIED, the specification of the priv is ignored, the specified object will not be displayed on screen, and thus the specified subject (or subjects) cannot operate (view or update) the specified object. When both VIEW and UPDATE are
authorized on the same object, the VIEW privilege overrides the UPDATE privilege to conform to the principle of least privileges [13]. In addition, the authorization rules for the lower level nodes take precedence of the authorization rules for the higher level nodes in the WIS hierarchy. 4. prop: It represents the propagation policy for the authorization rule. As shown in Fig. 1, the Personnel Dept → Personal Data → Add → Add.html is a navigation path. Due to the hierarchy of WISs, it makes no sense to authorize a user to be able to view Add.html without allowing the user to view Personnel Dept, Personal Data, and Add. Thus, in the schema, the value of the prop attribute is fixed as “CASCADE” to indicate that, whenever the access to a node is granted, the authorization will be automatically applied recursively to all its parent nodes. 3.4. Menu generation process WISs can be expressed as a set of inter-related menus. Each menu represents a view that a user is authorized to use. And a click on a menu button will
Fig. 7. (a) The schema for authorization rules and (b) an example authorization rules complying to (a).
1114
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 8. Menu generation process.
trigger a program to generate a menu or a web page that contains HTML form components which allows users to interact with backend systems. The above process is depicted in Fig. 8. The process can be divided into menu generation stage and view generation stage. 1. Menu generation stage: It is assumed that an individual user’s identification is verified successfully and the communication channel between the client and the web server is secured. The menu generator uses the configuration files for the WIS hierarchy and the authorization rules to generate a menu structure for the user. The newly generated menu structure is also described in XML. 2. View generation stage: After user’s menu structure is obtained, it is processed by the view generator to generate a view. The view can be expressed in HTML, WML, or any other formats that can be processed by XSLT. Note that, if WML pages are generated, the proposed model can also be used for information retrieval using cellular phones. Also, as long as the schemata for the WIS hierarchy, user information, and authorization rules remain unchanged, all XSLT files and two generators do not have to be re-written for other WISs.
documents into menus (in XML) and views (in HTML or WML) as shown in Fig. 8, we deployed XSLT for the transformations. Apache’s Xalan is used for processing XML and XSLT files. Due to the hierarchical structure of WISs, it is likely that a user is only authorized to the nodes A, B, F, and L as shown in Fig. 9. Therefore, the user has to navigate from node A, node B, node F, and then to node L to perform a specific task. This is tedious. For convenience, in our implementation, node L will be displayed to the user after logging in. Supposed that Bob is a manager of a company and has access to almost all functions of the example WIS. Because the salary of an employee is a sensitive data, it can only be updated by a privileged user such as Bob. For separation of duty, Bob does not enter data for new employees, but he is authorized to view all user’s information. The authorization rules for Bob are shown in Fig. 7(b). In Fig. 7(b)(1), because the path of the authorization rule is “/Menus”, Bob is authorized to access all functions of the example WIS, and this
4. Implementation To verify the effectiveness of the proposed model, a prototype was developed. Also, to ease the maintenance burden, administrative tools were implemented to manage the user information, authorization rules, and WIS hierarchy. For portability, we chose Java to develop the prototype. Because the user information, authorization rules, and WIS hierarchy are all encoded in XML; and because we need to transform the XML
Fig. 9. An example of reduced navigation path.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
results in the view as shown in Fig. 11(a) after he logs in. Fig. 7(b)(2) forbids Bob to enter data for new employees whose menu id is “M-0000-000004”. Additionally, Fig. 7(b)(4) indicates that Bob is authorized to update the salary field, whose id is “E-0000-000132”. As for other employee information, Bob is authorized to view which is shown in Fig. 7(3). The last two rules determine the view on the Update menu as shown in Fig. 12(a). Moreover, since Bob is allowed to update an employee’s salary, a label and a textfield for entering salary are shown in Fig. 12(a). Tom is a staff of the personnel department of the company and allowed to enter data for new employees except for the salary field. Tom also has the privileges to update and query all the employees’ data except for the salary filed. The authorization rules for Tom are shown in Fig. 10. As shown in Fig. 10(a) and (c)–(e), Tom is not authorized to access the systems developed for accounting, manufacturing, and administration departments whose menu IDs are “M-0000-000009”, “M-0000-000019” and “M-0000-000021”, respectively. Tom is not authorized to view the salary field of all employees and,
1115
thus, Fig. 10(f)–(h) prevent him from viewing it in the Add, Update, and Query menus. The element IDs of the salary fields in the Add, Update, and Query menus are “E-0000-000013”, “E-0000-000132”, and “E-0000-000152”, respectively. Fig. 11(b) is the view that is generated based on Tom’s privileges after he logs in. Because Tom is not authorized to use any function designed for the accounting, manufacturing, and administration departments, there are no “Accounting Dept”, “Manufacturing Dept”, and “Administration Dept” buttons as shown in Fig. 11(b). This feature prevents users from performing tasks that they are not allowed and, thus, decreases errors and system’s resources. Furthermore, Tom is authorized to update employee’s data except for the salary field. Therefore, Tom’s view on the Update menu is shown as Fig. 12(b). Without the salary field displayed in the page, errors and unauthorized actions can be avoided. There is one important feature that is hidden in Fig. 12. The “Submit” buttons in both Bob’s and Tom’s views are pointed to one identical program whose URL is: http://localhost/servlets/UpdateProcess
Fig. 10. Tom’s authorizations.
1116
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
Fig. 11. (a) Bob’s and (b) Tom’s views on the example WIS.
as defined in line 25 of Fig. 5. However, the “behavior” of the program is partially dependent on who invokes it. On one hand, when Bob clicks on the “Submit” button, only the salary field is updated. On the other hand, when Tom clicks on the “Submit” button, all values of the Address, Department, and Experience
fields are updated. The number of fields to be updated is determined by the authorization rules of the user. Because Tom is authorized to enter data for new employees and query employee’s information except for the salary field, the Add and Query menus that Tom are authorized to use are shown in Fig. 13(a) and (b),
Fig. 12. (a) Bob’s and (b) Tom’s views on the Update menu.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
1117
Fig. 13. Tom’s view on the (a) Add and (b) Query menus.
respectively. In the Query function, Tom is authorized to query the values of the Username, Address, Department, and Experience fields. Also, he can selectively choose which fields he want to see using the “checkbox” options as shown in Fig. 13(b). Again, the number of fields to be displayed is determined by the authorization rules of the user.
5. Discussions We proposed an access control model, called XMenu, as well as design and implement a prototype for an example WIS. Throughout the development, we observed the following benefits of the proposed model: 1. Fine-grained control: The X-Menu model uses XML to model the user information, WIS hierarchy, and authorization rules. Therefore, we can specify authorizations on a whole document, elements (with or without sub-elements), and attributes. 2. Flexibility: The X-Menu processor deploys credential-based security policies. Based on user properties, we can specify an authorization rule to a user’s property such as group and department. Therefore, the proposed model provides flexible
authorization specifications, and the cost for authorization management is reduced. 3. Security: It is important to ensure the security of data transmitted over Internet. Also, many existing WISs use username and password to authenticate users. By incorporating the proposed model with Secure Socket Layer (SSL) services on web servers, a secure environment is ensured. 4. Low maintenance cost: In the proposed model, all information are expressed in XML. Due to the XML design principle of the separation of content and layout, one document can be applied to different stylesheets to generate different web pages. Whenever the content of the document is modified, nothing has to be done by developers. Also, as stated earlier, the number of programs and XML documents that need to be maintained in the proposed model is much smaller than the number of programs in RBAC models. For example, in considering the first two levels of the example WIS in Fig. 1, we need to maintain, in the worst case, 8 × (3! + 2! + 2! + 2!) programs by using RBAC models. (To reach the Node1, “Personnel Dept” in the Node0 has to be selected. There are eight possible menu combinations that include “Personnel Dept”. In the Node1, there are 3! possible menu combinations. Thus, we have a total of 8×3!
1118
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119
menu combinations. Similarly, the possible menu combinations for the Node2, Node3, and Node4 are all 8 × 2!.) While only (4 + 3 + 2 + 2 + 2) programs and five XML documents (including two XSLT stylesheets and three configuration files) are required to be maintained in the X-Menu model. 5. Error prevention: Practically, in the design of information systems, we like to reduce the chances that errors may occur and avoid any unauthorized action to endanger systems. Therefore, for any function that a user is not authorized to perform, the function should not be displayed in front of the user. We deployed such design principle in the proposed model, and thus any function that the user is not authorized to perform will be hidden from the user to prevent errors. 6. Personalization: In contemporary enterprises, personalization or customization is very important in keeping good relationships with customers or suppliers. By adapting the X-Menu model, we can easily provide personalized web pages for users based on their preferences.
6. Conclusions WISs have become mainstream systems on the Internet. However, the development of access control for WISs is still in its infancy stage. Although there exists many access control models for web applications, they are not suitable for WISs. In this paper, we proposed an access control model for WISs. Also, a prototype had been designed and implemented. The proposed model provides fine-grained control up to the element level of web pages and is flexible and secured. Any unauthorized action is prevented from performing by users. Because the number of programs and XML documents that need to be maintained in the proposed model is much smaller than the number of programs in RBAC models, the maintenance cost is low. To make maintenance even easier, some utility programs can be developed for the management of XML documents for describing WIS hierarchy, user information, and authorization rules. The maintenance work can be further reduced if native XML databases [8] such as Tamino [1] and eXcelon [12] are employed.
In the current design of the proposed model, the authorization specification is based on user’s properties and, therefore, can be further extended to incorporate the concept of role to provide a better control mechanism for WISs in the future. Also, in our model, we assume that there is only one WIS for a web server. We wish to extend the proposed control model to the cases of multiple WISs in one web server or distributed in different web servers managed in a federated manner in the future.
Acknowledgements This research was partially supported by the National Science Council, Taiwan, ROC, under contract number NSC91-2213-E-324-015.
References [1] Software AG, Tamino XML server. http://www.softwareag. com/tamino/. [2] S.W. Ambler, Mapping objects to relational databases, Ronin International, 2000. http://www.AmbySoft.com/ mappingObjects.pdf. [3] E. Bertina, Data security, Data Knowledge Eng. 25 (1998) 199–216. [4] E. Bertino, B. Carminati, E. Ferrari, XML security, Inform. Security Tech. Rep. 6 (2) (2001) 44–58. [5] E. Bertino, S. Castano, E. Ferrari, Securing XML documents with Author-X, IEEE Internet Comput. 5 (3) (2001) 21–31. [6] E. Bertino, S. Castano, E. Ferrari, M. Mesiti, Specifying and enforcing of access control policies for XML document sources, World Wide Web J. 3 (3) (2000) 1–25. [7] E. Bertino, E. Pagani, G.P. Rossi, P. Samarati, Protecting information on the web, Commun. ACM 43 (3) (2000) 189– 199. [8] R. Bourret, XML and databases. http://www.rpbourret.com/ xml/XMLAndDatabases.htm. [9] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, Design and implementation of an access control processor for XML documents, Comput. Networks 33 (2000) 59–75. [10] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, A fine-grained access control system for XML documents, ACM Trans. Inform. Syst. Security 5 (2002) 169– 202. [11] E. Damiani, P. Samarati, S. De Capitani di Vimercati, S. Paraboschi, Controlling access to XML documents, IEEE Internet Comput. 5 (6) (2001) 18–28. [12] eXcelon Corporation, eXtensible Information Server (XIS). http://www.odi.com/products/xis/.
E.J.-L. Lu, R.-F. Chen / Future Generation Computer Systems 19 (2003) 1105–1119 [13] D.F. Ferraiolo, J.F. Barkley, D. Richard Kuhn, A role-based access control model and reference implementation within a corporate Intranet, ACM Trans. Inform. Syst. Security 2 (1) (1999) 34–64. [14] T. Isakowitz, M. Bieber, F. Vitali, Web information systems, Commun. ACM 41 (7) (1998) 78–80. [15] J.B.D. Joshi, W.G. Aref, A. Ghafoor, E.H. Spafford, Security models for web-based applications, Commun. ACM 44 (2) (2001) 38–44. [16] H. Maurer, Modern WISs, Commun. ACM 41 (7) (1998) 114–115. [17] J.S. Park, R. Sandhu, Role-based access control on the web, ACM Trans. Inform. Syst. Security 4 (1) (2001) 37–71.
1119
[18] P. Samarati, E. Bertino, S. Jajodia, An authorization model for a distributed hypertext system, IEEE Trans. Knowledge Data Eng. 8 (4) (1996) 555–562. [19] R.S. Sandhu, P. Samarati, Access control: principles and practice, IEEE Commun. Mag. 32 (9) (1994) 40–48. [20] K. Takahashi, Metalevel links: more power to your links, Commun. ACM 41 (7) (1998) 103–105. [21] K. Takahashi, E. Liang, Analysis and design of web-based information systems, Comput. Networks ISDN Syst. 29 (1997) 1167–1180. [22] Z. Tari, S.-W. Chan, A role-based access control for Intranet security, IEEE Internet Comput. 1 (5) (1997) 24–34.