以剖面導向程式語言研製 Web 應用程式安全框架
計畫類別： 個別型計畫
計畫編號： NSC93-2213-E-004-009-
執行期間： 93 年 08 月 01 日至 94 年 07 月 31 日
執行單位： 國立政治大學資訊科學系
計畫主持人： 陳恭
計畫參與人員： 黃植懋、林經緯、黃啟峰、張淵鈞
報告類型： 精簡報告
報告附件： 出席國際會議研究心得報告及發表論文
處理方式： 本計畫涉及專利或其他智慧財產權，1 年後可公開查詢
中 華 民 國 94 年 10 月 24 日
摘要
安全相關的程式碼必須嵌入到應用系統
的 各 個 模 組 中 去 執 行 ， 具 有 橫 跨
(cross-cutting)的特性。在設計時，若不加
以區分，仍然以一般的物件或是函式模組
來將其模組化的話，往往造成系統中反覆
出現類似的程式碼以及不同需求的程式
碼夾雜不清的現象，結果導致系統不易維
護且錯誤頻仍。最近興起的剖面導向程式
設計(Aspect-Oriented Programming)基於
關注分離的原則，針對像安全這類橫跨性
的需求，倡議在原有的物件或函式模組
外，另以方面(aspect)作為這些橫跨性需求
的模組單位，以大幅改善應用系統的模組
性。本計畫以剖面導向的原則，以 AspectJ
語言為主要工具，針對 Web 應用程式在
認證與權限方面的安全需求設計與製作
一套安全框架。此外，透過此一建構的經
驗我們也對 AspectJ 語言進行分析，評估
其 剖 面 模 組 在 重 用 性 上 的 特 性 與 優 缺
點，作為其日後可能改進之參考。
關鍵詞
：剖面導向程式設計，全球資訊
網，安全框架，認證，權限，
Abstract
Security concerns such as authentication
and access control are system-wide
concerns that have both a generic nature
and an application dependent characteristic.
They are generic as many functions must be
protected with restricted access, yet the rule
to grant a request is highly dependent on the
application state. Hence it is common to see
the code for implementing access control
scattered over the system and tangled with
the functional code, making the system
difficult to maintain. This paper addresses
this issue for Web applications by
presenting a practical access control
framework based on aspect-oriented
programming (AOP). Our approach
accommodates a wide range of access
control requirements of different granularity.
AOP supports the modular implementation
of access control while still enables the
code to get a hold of the application state.
Moreover, framework technology offers a
balanced view between reuse and
customization. As a result, our framework is
able to enforce fine-grained access control
for Web applications in a highly adaptable
manner.
Keywords: Aspect-Oriented Programming,
Security framework, Authentication, Access
control, Web applications
1. 前言
應用系統的安全防護有許多面向，其
中 又 以 認 證 與 授 權 (Authentication &
Authorization, A&A) 為 基 礎 核 心 。 認 證
(Authentication)是 A&A 架構的第一道關
卡，指的是要辨認使用者(可以是人員或程
式)的身份；授權(Authorization)就是資源
的存取控管(Access Control)，用以判定使
用者是否有權使用特定的資源。授權是安
全政策管理(Security Policy Administration)
的核心工作項目，主要目的在於根據安全
政策給予使用者所能擁有的權限，以確保
系統資源的不致遭到不當使用。授權有效
運作的前提是辨識使用者的身份，所以討
論權限管理就必然包含確認使用者已完
成身份認證的部分，所以以下我們將多以
存取控管來稱謂認證與授權的管理。
一般應用系統的開發大多以系統的功
能需求為主要的考量對象，對安全方面的
需求雖然或多或少都會加以搜集整理，但
通常都是在系統開發進入一定階段後才陸
續將安全需求納入設計與實作中，欠缺一
套貫穿需求蒐集、系統分析、系統設計到
程式撰寫的開發方法與工具。這樣的作法
不僅容易因缺乏整體性考量而造成安全疏
失外，對於是否能完整貫徹安全需求於系
護核心的存取控管自然也面臨同樣的問
題 ， 無 怪 乎 在 Open Web Application
Security Project (OWASP)所公佈的 2004
Web 應用程式十大安全弱點中，”Broken
Access Control”高居第二位[15]。
造成這樣的問題其實其來有自，這裡
面除了管理上是否能落實安全品管與開
發人員經驗是否充足外，從更基礎的技術
層次來看，我們認為系統開發人員與管理
人 員 往 往 受 限 於 現 有 的 程 式 機 制
(programming mechanism)、開發工具與架
構，而無法盡如所願的對各個應用系統進
行徹底的安全防範措施。因為傳統的開發
工具與程式語言也是以滿足縱向的功能
需求為主，欠缺支援像安全需求這樣橫跨
性的功能，使得貫徹安全需求的程式碼必
須散落在系統的各個模組中，與系統功能
面的程式碼糾結(tangled)在一起，不但不
易確認其正確性，也對修改維護上造成相
當大的負擔。
2. 研究目的
有鑑於現行程式機制與開發工具無法
有效支援像安全這樣的橫跨性需求，目前
學者專家提出了剖面導向程式設計的構
想 (Aspect-Oriented Programming)[12]，以
有效支援橫跨性需求的發展與整合。AOP
的原則就是軟體工程上著名的關注分離
原則 (Separation of Concerns)，它強調橫
跨性的需求應該與縱向的功能需求有所
區隔，程式開發工具應該要提供不同的模
組機制來分別支援二者，並提供整合機制
將二者的模組整合成完整的程式，其中橫
跨性需求的模組單位稱之為 aspect，整合
的動作則稱為織入(weaving)。
本計畫根據 aspect-oriented 的原則，採
用 AspectJ 語言為主要工具，研究如何針
對 Web 應用程式的 A&A 需求，發展一套
Framework [6]。以下是我們的研究目地：
(1) 整理 Web 應用程式的各種 A&A 的
常 用 需 求 與 程 式 實 作 結 構 ， 以
aspect-oriented 的角度分析這些實作
結構的共通性與特殊性關係。
(2) 將這些結構性關係推廣、一般化，以
AspectJ 語言發展出一組可重用的
aspects，據以建構一可實現這些方
案的框架與程式庫。
(3) 評估 AspectJ 語言的重用機制的設
計，分析其特性與優缺點。
3. 文獻探討
因篇幅關係，請參照附錄一我們發表
的論文” A Practical Aspect Framework for
Enforcing Fine-Grained Access Control in
Web Applications”中 Related Work 一節中
的說明。
4. 研究方法
我們從 A&A 安全需求分析以及剖面導
向技術機制的設計分別著手。在 A&A 需
求分析方面，我們以<user, function, data>
的角度來捕捉應用系統使用者與系統間
的互動與存取控管的需求，表示某 user 提
出執行一 function 的要求並可能會存取某
些 data。這樣的方式不僅合乎直覺，也可
以充份掌握不同細緻度(granularity)的存
取控管需求，其中 user 層級表示控管規則
只要求確認使用者的身份及可，屬於最粗
的控管層級(coarse-grained)，function 層級
次之，因為某些 function 的執行需要使用
者滿足進一步的控管限制；data 層級最為
細緻(fine-grained)，使用者跟所欲存取的
資料之間必須符合特定的限制條件。例
如，在 B2C 應用程式中，商品瀏覽與選購
是不需身份認證就可以執行的，但是要結
帳下單就必須先確認其身份，這就是 user
層級的控管；下單後，訂單的查詢瀏覽就
只能限於屬於自己的訂單，而不能看別人
的，這就是 data 或 instance 層級的控管。
尤有甚者，顯示訂單內容時，應該將如信
用卡號碼等敏感資料欄位隱藏，這是 field
層級的控管。我們採用下列形式的存取控
管規則來模型化這些需求：
Rule: <funName, authType,
dataClassName[-fieldNames], constraint>
其中 funName 指的是被限制存取的功能函
式名稱，dataClassName 則是在函式中被存
取的物件型態，fieldNames 則是指明了哪
些物件的屬性(欄位)是必須加以限制不讓
使用者看到的，這些屬性的資料在呈現給
使用者之前會被遮蔽(Mask) ; 如果沒有列
出，則表示使用者可存取物件中所有的屬
性。其次，authType 表明執行此功能必須
先通過的認證方式(password or digital
certificate, etc.)。最後的 constraint 則是用
來決定是否允許使用者的存取要求，它是
一個布林函式，我們採用了一些基本的關
聯運算子，像是等於(equals)、小於(less)，
以及集合運算等，方便權限管理者來制訂
constraint 表達式(expression)。例如，”使
用者必須以 password 認證後才能查詢訂
單，而且只能瀏覽自己的訂單，並不得顯
示信用卡號碼”，就可以表示成下列規則：
Rule:<viewOrders, PWD,
Order[-creditCardNumber],
equals(User.getAttr(“Name”),
Data.getAttr(“Owner”))>
其次，在支援 A&A 的程式機制方面，
我們設計了一套 Aspect framework 來貫徹
這些存取控管規則的程式，並且以 AspectJ
為工具搭配 OO framework 的技術來實
現。我們以採用知名的 Apache Struts[1]結
構的 Web 應用程式為標的，並充分地貫徹
了上述各類的存取控管規則。
因篇幅關係，Framework 的細節請參照
附錄一我們發表的論文中的第二與第三
節的說明。對於 AspectJ 在重用性方面的
討 論 請 參 照 附 錄 二 論 文 ”On Designing
Access Control Aspects for Web
Applications”一文第四與第五節的說明。
5. 結果與討論
本計畫的結果已發表於兩篇國際會議
論文與兩篇碩士論文，因篇幅關係，成果
的細節與討論請參照附錄一與附錄二我
們所發表的論文。
6. 參考文獻
[1] The Apache Struts Web Application Framework:
http://struts.apache.org/
[2] Chandramouli, R.: A Framework for Multiple
Authorization Types in a Healthcare Application
System,
17th Annual Computer Security
Applications Conference, Dec. 2001, New
Orleans, Louisiana.
[3] De Win, B., Piessens, F., Joosen, W. and
Verhanneman, T., On the importance of the
separation-of-concerns principle in secure
software engineering, Workshop on the
Application of Engineering Principles to System
Security Design, 2002.
[4] De Win, B., Vanhaute, B., and De Decker, B.,
Building Frameworks in AspectJ, ECOOP 2001,
Workshop on Advanced Separation of Concerns,
pp.1-6.
[5] De Win, B., Vanhaute, B. and De Decker, B.,
Security Through Aspect-Oriented Programming,
Advances in Network and Distributed Systems
Security, Kluwer Academic, pp. 125-138, 2001.
Building Software Frameworks in AspectJ, 2nd
AOSD Workshop on Aspects, Components, and
Patterns for Infrastructure Software (ACP4IS),
Boston, MA, March 17, 2003.
[7] Gamma, Helm, Johnson and Vlissides: Design
Patterns. A. W. L., 1995. ISBN 0-201-63361-2.
[8] Georg, G., Ray, I., and France, R., Using Aspects
to Design a Secure System, Proc. of the 8th IEEE
Int’l Conf. on Engineering of Complex Computer
Systems. December 2002.
[9] Georgiadis, C.K., Mavridis, I., Pangalos, G., and
Thomas, R.K.: Flexible Team-based Access
Control Using Contexts, Sixth ACM Symposium
on Access Control Models and Technologies
(SACMAT 2001), Chantilly, VA, USA, May 2001.
[10] Giuri, L., and Iglio, P., Role Templates for
Content-Based Access Control, Proceedings, 2nd
ACM Workshop on Role-Based Access Control,
Fairfax, VA (October 28–29, 1997), pp. 153-59.
[11] Goodwin, R., Goh, S.F., and Wu, F.Y.,
Instance-level access control for
business-to-business electronic commerce, IBM
System Journal, vol. 41, no. 2, 2002.
[12] Kiczales, G., Lamping, J., Menhdhekar, A.,
Maeda, C., Lopes, C., Loingtier, J.-M., and Irwin,
J., Aspect-Oriented Programming, in ECOOP '97,
LNCS 1241, pp. 220-242.
[13] Kiczales, G., Hilsdale, E., Hugunin, J., Kersten,
M., Palm, J., and Griswold, W.G., Getting Started
with AspectJ, Communications of ACM, vol. 44,
no. 10, pp 59-65, Oct. 2001.
[14] Kouadri Mostefaoui, G., and Brezillon, P., A
generic framework for context-based distributed
authorizations, In: Modeling and Using Context
(CONTEXT-03), LNAI 2680, Springer Verlag, pp.
204-217.
Top Ten Most Critical Web Application Security
Vulnerabilities.
http://www.owasp.org/documentation/topten
[16] Sandhu, R., Coyne, E., Feinstein, H., and
Youman, C., Role-Based Access Control Models,
IEEE Computer, 29(2):38–47, 1996.
[17] Sun Microsystems, Java Authentication and
Authorization Service (JAAS),
http://java.sun.com/products/jaas/index.jsp
[18] Sun Microsystems, JavaServer Pages
Technology (JSP):
http://java.sun.com/products/jsp/
[19] Sun Microsystems, Java Servlet Technology :
http://java.sun.com/products/servlet/
[20] Tzelepi1, S.K., Koukopoulos, D.K., and
Pangalos, G.: A flexible Content and Context-based
Access Control Model for Multimedia Medical
Image Database Systems. ACM SIGMM Electronic
Proceedings, 2001
.
7. 計畫成果自評
本計劃的成果包含：
(1)一套可用來捕捉 Web 應用程式的各種
A&A 常用需求的高階規則描述式，可
方便安全管理人員與系統開發人員溝
通與制定系統 A&A 安全需求與規
則。
(2)以 AspectJ 語言發展出一組可重用的
aspects，並據以建構一可實現這些方
案的框架與程式庫。
(3) 從 A&A 的安全 aspect 製作經驗，評估
了 AspectJ 語言的重用機制的設計，分
析其特性與優缺點。
這些成果已發表於兩篇國際會議論文
與兩篇碩士論文，在內容上也與當初計畫
所設定的目標非常接近。
附錄一與附錄二維所發表的論文。
Robert H. Deng et al. (Eds.): ISPEC 2005, LNCS 3439, pp. 156–167, 2005. © Springer-Verlag Berlin Heidelberg 2005
A Practical Aspect Framework for Enforcing
Fine-Grained Access Control in Web Applications
Kung Chen and Chih-Mao Huang
Department of Computer Science, National Chengchi University, Wenshan, Taipei 106, Taiwan
{chenk, g9224}@cs.nccu.edu.tw
Abstract. Access control is a system-wide concern that has both a generic
na-ture and an application dependent characteristic. It is generic as many functions must be protected with restricted access, yet the rule to grant a request is highly dependent on the application state. Hence it is common to see the code for im-plementing access control scattered over the system and tangled with the func-tional code, making the system difficult to maintain. This paper addresses this issue for Web applications by presenting a practical access control framework based on aspect-oriented programming (AOP). Our approach accommodates a wide range of access control requirements of different granularity. AOP sup-ports the modular implementation of access control while still enables the code to get a hold of the application state. Moreover, framework technology offers a balanced view between reuse and customization. As a result, our framework is able to enforce fine-grained access control for Web applications in a highly adaptable manner.
1 Introduction
The principle difficulty in designing security concern such as access control into an application system is that it is a system-wide concern that permeates through all the different modules of an application. Although there is a generic need to enforce ac-cess control for protected resources, yet the specific constraint for granting acac-cess to each individual resource may not be the same. Hence in current practices it is very often to see the code for implementing access control scattered over the whole system and tangled with the functional code. This is not only error-prone but also makes it difficult to verify its correctness and perform the needed maintenance; Web applica-tions are no excepapplica-tions. Indeed, “broken access control” is listed as the second critical Web application security vulnerability on the OWASP top ten list [15].
A better way to address this problem is to treat security as a separate concern and devise a framework where the generic requirements of access control are captured and the resource-specific constraints can be encapsulated and separated from the func-tional part of an application [3]. This will not only improve the application’s modular-ity but also make the task of enforcing comprehensive access control more tractable. The Java Authentication and Authorization Services (JAAS) of J2EE [17] is a well-known attempt toward such a solution. Furthermore, it takes one step forward to
pro-vide declarative security where access control constraints can be specified declara-tively in a configuration file without actual coding. This makes access control highly adaptable.
While sufficient for meeting common access control requirements encountered in Web application development, there are many fine-grained requirements that cannot be satisfied in a modular manner using middleware services such as JAAS. Most notably are the cases when the access control constraints must be defined at the data level. For example, in a B2B E-Commerce site, users from any registered organiza-tions have the privilege to execute the “viewOrder” function, but they are allowed to view only orders of their own organization. This is called instance-level access con-trol constraints [11]. Furthermore, within a data record, certain specific fields, such as credit card number, may have to be excluded from screen view to protect the user’s privacy. We refer to this as field-level access control constraints. The declarative security mechanism of JAAS does not cover such fine-grained constraints; to handle them well, we still have to write scattered and tangled code.
It is thus highly desirable to devise a systematic approach and proper mechanisms to realize such fine-grained access control requirements for Web applications in a modular and adaptable manner. We worked toward this goal from two opposite ends and managed to meet in the middle. At one end, the objective is to accommodate requirements. We use a flexible modeling scheme based on user-function-data rela-tionship that can satisfy a wide range of access control requirements of various granu-larity levels, including both instance and field levels. At the other end, since access control is a system-wide crosscutting concern, we must impose considerable architec-tural disciplines on Web applications to layout a good foundation for enforcing the required access control modularly. In particular, we follow the well-accepted Model-View-Controller (MVC) [7] architectural pattern and adopt the popular Apache Struts framework [1] to structure our Web applications.
Next, to bridge these two ends, we devise a flexible implementation scheme that does not only support those access control requirements but also integrates seamlessly into the underlying application architecture. Specifically, the emerging techniques of aspect-oriented programming (AOP) [12] are employed to enforce access control constraints in Struts-based Web applications. We take full advantage of AspectJ [13] to design and implement an aspect framework that can meet the diverse information needs of those requirements while allowing reuse and application-specific customiza-tion. Furthermore, the codes that implement the required access control are encapsu-lated and linked to functional modules in a very low-coupling manner, rendering the resulting systems highly modular and adaptable.
The rest of this section gives a brief introduction to AspectJ and the Struts frame-work. Section 2 describes our approach to access control modeling. Section 3 presents our aspect framework in detail. Section 4 compares related work. Section 5 concludes and sketches future work.
1.1 AOP and AspectJ
AOP is a new programming paradigm to support separation of concerns in software development. It addresses the program modularity issues of a crosscutting concern through a new kind of modules, called aspect, and new ways of module composition.
158 K. Chen and C.-M. Huang
In AOP, a program consists of many functional modules, e.g. classes in OOP, and some aspects that captures concerns that cross-cuts the functional modules, e.g. secu-rity. The complete program is derived by some novel ways of composing functional modules and aspects. This is called weaving in AOP. Weaving results in a program where the functional modules impacted by the concern represented by the aspect are modified accordingly. In languages such as AspectJ, the weaver tool is tightly inte-grated into the compiler and performs the weaving during compilation.
To facilitate the weaving process, a set of program join points are introduced to specify where an aspect may cross-cut the other functional modules in an application. Typical join points in AspectJ are method execution and field access. A set of join points related by a specific concern are collected into a pointcut. Code units called
advice in an aspect are tagged with a pointcut and determine how the application
should behave in those crosscutting points. There are three kinds of advice in AspectJ:
before, after, and around. The before advice and the after advice are executed before
and after the intercepted method, respectively. The case for the around advice is more subtle. Inside the around advice, we can choose to resume the intercepted method by calling the special built-in method proceed(), or simply bypass its execution.
Furthermore, AspectJ also allows aspect inheritance, abstract aspect, and abstract pointcut. We can write an aspect without any reference to a join point by declaring the pointcut abstract. A sub-aspect then extends the abstract aspect and defines the con-crete pointcut. As we shall demonstrate later, these abstract aspects open the way to build generic aspects that are essential to an aspect framework.
1.2 Web Application Architecture and the Struts Framework
We follow the mainstream approach to Web application architecture that structures an application using the Model-View-Controller (MVC) architectural pattern [7]. The model components encapsulate the application components in the business logic and data tiers. The view components are those pieces of an application that display the information provided by model components and accept input. The controller is a spe-cial program unit that coordinates all the activities of the model and view compo-nents. It acts as a central point of control within an application.
Currently, most Web application frameworks are MVC-based. In particular, we choose the popular open source Struts framework [1]. It is compatible with Sun's J2EE platform and primarily based on Servlet [19] and JSP [18] technology. Figure 1 illustrates the structure of a Struts-based Web application. The controller is imple-mented using a dedicated ActionServlet with the assistance of an XML configuration file, struts-config.xml. Every user request is dispatched to an Action class by the
Ac-tionServlet according to the action mapping defined in the configuration file. These
actions are responsible for serving user requests or passing them to the correct busi-ness model components, and for returning the correct view element that the
Action-Servlet should forward to afterwards. This view forwarding is also based on the
map-ping information specified in the configuration file. The view element is often a JSP page, extended with custom tag libraries provided by Struts.
Fig. 1. Struts-Based Web application architecture
Moreover, the HTTP request object and the session object provided by the Servlet framework serve as the shared data repository between action classes and JSP views. User input captured via an ActionForm is stored in the two objects; action classes also put their execution results in these objects. Hence JSP views can fetch both user input and execution results from them for display. For example, user authentication results and user profiles are kept in the session object for authorization and other purposes.
2 Access Control Modeling
Access control, also known as authorization, is a process by which users, after being identified, are granted certain privileges to information, system functions, or re-sources. The step to identify a user is usually called authentication. Username and Password check is the most basic form of authentication, while digital certificates and biometrics are more advanced ways of authentication.
Since RBAC [16], there have been many approaches proposed to model access control requirements for applications purposes. Here we take a simple yet generic approach that can support a wide range of access control requirements. We model the interaction between a user and a Web application as a sequence of access tuples of three elements: <user, function, data>, indicating a user’s request to execute the function on a specific type of data object(s). The access control rules of an application determine which access tuples are allowed and which must be denied. They are de-rived from the application’s access control requirements.
In designing the form of our access control rules, we focus on the functionalities of an application and specify the access control rules in a function-oriented manner. Furthermore, as authentication is required prior to authorization, we also make
“Au-thenticationType” part of the rule; the type can be id/password (PWD), digital
certifi-cate (DC), or any other supported methods of user identification. Specifically, the access control rules take the following form:
Rule: <funName, authType, dataClassName[-fieldNames], constraint>
Access Control Aspect Controller (ActionServlet)
Struts
struts-config.xml Business Model Component DB B rows er Model ActionForm Action View (JSP) HTTP Request/ Session Objects160 K. Chen and C.-M. Huang
Here funName is the name of a function whose access needs to be restricted, authType is the required user authentication type, and dataClassName refers to the type of the data objects being operated by funName. Note that [-fieldNames] following
data-ClassName is optional; when present, it specifies the list of fields whose contents
must be masked before presenting the data object(s) in context to the user. Last, the
constraint is a Boolean expression which must be evaluated to true to grant the
at-tempted access. We assume a few basic relational operators, such as equal, less and set membership, available for specifying the constraint expression. If the constraint does not refer to any information on the data object, the dataClassName element can also be left unspecified as “__”.
Clearly, the more related entities we can refer to in the constraint expression the wider the scope of access control requirements we can support. For generic purposes, we take an object-based approach to specify the constraints and supply three generic objects: User, Fun, Data, with various attributes that the constraint expression can refer to. Typical attributes for the User object include user’s name and roles in an organization. The attributes of the Fun object include the function’s full name and the arguments passed to it, while the fields of the dataClassName are the default attrib-utes of the Data object to support fine-grained control. The specific set of attribattrib-utes depends on individual application’s needs.
Furthermore, to accommodate more access control requirements, we provide an-other two objects for specifying the constraints. First, the context object (Cxt) pro-vides methods to retrieve the time and location of the attempted access. This is the most often used contextual information for access control. Second, the application object (App) is global to an application and stores various specific parameters related to access control. For example, certain functions are accessible only during working days and from specific machines. These application-wide parameter definitions can be provided easily through a standard Java property file.
Example: The following is a set of access control requirements and corresponding rules for a typical online shopping and order management system. Note that “&&” stands for the and operator, and “||” the or operator.
C1: Only registered (authenticated) users can search the detailed product catalog. R1: <searchDetailedCatalog, PWD, __, true>
C2: All registered users (a.k.a. customer) can create order, but only VIP customers can create orders whose total amount exceed $100,000.
R2: <createOrder, PWD, __, ( lessEq(Fun.getArgument(“total”), 100000)
|| equals(User.getAttr(“VIP”), true) ) >
C3: Only sales managers authenticated through digital certificates can delete order objects.
R3: <deleteOrder, DC, Order, contains(User.getAttr(“Roles”), “Sales”)
&& contains(User.getAttr(“Roles”), “Manager”)>
C4: Customers can list (view) their own orders, but the credit card number should be excluded from display.
R4: <listOrders, PWD, Order[-creditCardNumber],
equals(User.getAttr(“Name”), Data.getAttr(“Owner”))>
C5: Unclassified orders can be printed in batch mode by sales from dedicated ma-chines during working days.
R5: <batchPrintOrder, PWD, Order,
contains(User.getAttr(“Roles”), “Sales”)
&& contains(App.getAttr(“WorkingDays”), Cxt.getDay())
&& contains(App.getDedicatedMachines(), User.getAttr(“clientIP”)) && equals(Data.getAttr(“SecurityLevel”), “Unclassified”)>
This form of access control rules is very flexible and can model a multitude of re-quirements, from simple RBAC to sophisticated instance and field level constraints.
3 Building the Aspect Framework
This section describes our design of the aspect framework and presents it in detail. 3.1 Choosing the Pointcuts
As stated earlier, access control is a cross-cutting concern that AOP aims to modular-ize well. Yet, it is not something like function tracing that is completely orthogonal to the functions and all one has to do in AOP is to define the functions to be traced as the pointcuts without any involvement form the underlying functions. In contrast, access control decisions, especially fine-grained ones, need substantial information from the application about the context in which the decisions are required. Hence access con-trol aspects depend on the cooperation from the application to a significant degree. On the other hand, as we are not inventing a totally new style of application architecture, we need to carefully look for the proper pointcuts to weave in aspects so that a suit-able balance between information need and non-invasiveness is achieved.
Given the requirements above, central to our design of the aspect framework is to determine which type of program units in a Struts-based application to weave in the aspect code. This in turn is greatly influenced by the following design considerations. First of all, all the information required for enforcing access control rules and filtering out unauthorized contents must be available to the aspect code, since fine-grained access control cannot be realized without detailed application state. Second, in case that the attempted access must be denied, exception propagation and handling must not incur significant impacts on the program structure. Third, the correspondence between an access control rule and an enforcing aspect should be direct and clear for management and maintenance purposes.
Based on these considerations, we conducted some experiments and investigation. Finally, we choose the user action classes in Struts as the targets for access control aspect weaving. Action classes play the role of gateway between the presentation tier
162 K. Chen and C.-M. Huang
and the business and the data tiers. All action classes must inherit from the class
Ac-tion and implement an
execute
method1 with the following signature: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req,
HttpServletResponse resp)
It turns out that the execute method is indeed the proper join point to weave in our advice code for its arguments expose the right information we need. Firstly, user input and any intermediate results, including user authentication records and user profiles, are all stored in the request or session objects, which are available through the HttpServletRequest argument, req. Therefore, via the args() pointcut of AspectJ, our aspects will have all the information needed for enforcing the access control and filtering out unauthorized contents.
Secondly, the control transfer between actions and views is specified in the
struts-config.xml file, and is realized through the action mapping argument passed to the
method and the ActionForward object returned by an action class. Hence we can define proper exception pages in the configuration file and forward to them when an access request must be denied. Apparently, this exception handling scheme fits very well into Struts. Lastly, as will be shown later, an access control rule corresponds to its enforcement aspect quite directly since a user function will usually be supported by an action class.
3.2 Constructing the Aspects
Having chosen the user actions as our weaving targets, the next step is to investigate the structure of access control aspects for the framework’s purpose. Following the general spirit of framework construction [4][6], we shall divide the aspect code into two parts: generic part realized by abstract aspects and rule specific part realized by concrete aspects. This division is derived from a detailed analysis of the nature of information needed for enforcing the various kinds of access control rules presented in Section 2. The rule specific part of an aspect is easier to grasp. It is obvious that the authentication type, pointcut definitions, the constraint to check, and the removal of unauthorized contents are specific to each individual rule. The interesting case is the generic part of the access control aspects. For this, we must look into the inner struc-ture of the access control rules and constraints.
3.2.1 Authentication Aspects
Firstly, the simplest type of access control is indeed user authentication. Here the main concern is how to accommodate different schemes of user authentication. Be-sides, since all access controls must be preceded by proper user authentication, we shall make the various authentication codes available to all aspects in the framework. This is achieved by defining a root aspect that also acts as the factory of authentica-tion objects. We call this root aspect AAAspect2and here is its code:
1
Since Version 1.1, Struts also supports method-based dispatch units through a new class called DispatchAction. This can also be covered by our framework with little adaptation.
2
public abstract aspect AAAspect {
abstract pointcut pc(..);// arguments omitted abstract protected String getAuthType();
private static Hashtable authTable = new Hashtable(); static {
authTable.put("PWDAuth",PWDAuth.getInstance()); authTable.put("DCAuth", DCAuth.getInstance()); … // other authentication schemes }
protected Authentication getAuthObj(){ //factory method return (Authentication)authTable.get(getAuthType()); }
}
The getAuthObj() method is the factory method that will return the right authen-tication object according to the result of executing the getAuthType() method, which is rule specific and defined in concrete aspects. For each authentication type, there will be a singleton authentication object containing the code to verify that a user has passed the identification check and the login page name for re-direction purpose in case the user has not. These objects are instantiated from subclasses of the Au-thentication class, which prescribes the interface for verifying authentication checks (i.e., isAuthenticated()) and for obtaining the re-direction page (i.e., forwardTo()). In the code listing above, we have included two such objects instan-tiated from class PWDAuth and class DCAuth.
The user authentication task is a coordinated work between authentication aspects and authentication objects. Authentication aspects are responsible for invoking the methods of right authentication objects to perform the check at right places according to the access control rules. We factor out the common code of authentication aspects into the Authentication aspect and leave to its sub-aspects, e.g., PWDAuthAspect, the specifications regarding where to do the checking (pointcut) and which type of authentication to use. Here is the code for the Authentication aspect:
public abstract aspect AuthenticationAspect extends AAAspect{ ActionForward around(..) : pc(..) { // arguments omitted Authentication auth = getAuthObj(); // factory call if (auth.isAuthenticated(request))
return proceed(mapping, form, request, response); else // login re-direction
return mapping.findForward(auth.forwardTo()); }
}
3.2.2 Access Control Aspects
The structure of our access control aspects is determined by the constraints in access control rules. Specifically, the availability of the information referenced in the con-straints, such as user roles, function arguments and data contents, will shape the struc-ture of our aspect codes. We now explain how this relates to our design as follows.
As described earlier, in Struts-based Web applications, user profile information, user input, and any execution results are all kept in the session object or the request object, hence accessible to the aspect code3. The real issue here is when the required
3
164 K. Chen and C.-M. Huang
information is available. Previous work [4][5] tacitly assumed that the information is available to the aspect code for making the access control decision before executing the designated function. However, this is not the case for content-based fine-grained access control requirements. For instances, both rule R4 and rule R5 given in Section 2 need to examine the data contents to filter out unauthorized data. Such constraints cannot be enforced without first invoking the function requested.
A close look at the constraint expressions of R4 and R5 reveals that it is the refer-ence to the attributes of the Data object that calls for additional data filtering. Indeed, unlike the attributes of the User and Fun objects, the attributes of the Data object are not available before executing the designated function. Therefore, we propose two different kinds of access control aspects for realizing these requirements, namely
pre-checking and post-filtering. The pre-pre-checking aspects will handle the common cases
where the constraint involves only the User and Fun objects while the post-filtering aspects are needed if the constraint also refers to the attributes of the Data object.
Listing 1. The PostfilteringCollection aspect
public abstract aspect PostfilterCollection extends AAAspect { abstract protected Boolean
constraint(HttpServletRequest request);
private ActionForward forwardToErrorPage(..){ … };// omitted abstract protected boolean filter
(HttpServletRequest request, Object data); abstract protected Collection getRS(HttpRequest request); protected abstract void mask(Object data);
protected void remove(Iterator i) { i.remove();} // a record ActionForward around(..) : pc(..) { // arguments omitted Authentication auth = getAuthObj();
if (auth.isAuthenticated(request)) { //authentication check if (constraint(request)) { //privilege check
ActionForward forward = proceed(..); //resume Collection col = getRS(request);
Iterator i = col.iterator(); while(i.hasNext()){
Object data = i.next(); if (!filter(request, data))
remove(i); // unauthorized record else mask(data); // fields masking }
return forward; // completed } else // access denied
return forwardToErrorPage(request, mapping); } else // login re-direction
return mapping.findForward(auth.forwardTo()); }
}
Both pre-checking and post-filtering aspects must first get an authentication object and make a call to its isAuthenticated() method. This will ensure that access control enforcement is preceded by user authentication. Moreover, the advice in the post-filtering aspects must also conduct an access constraint check before proceeding
to execute the designated function and filter out unauthorized contents4. Since pre-checking aspects is the base for filtering aspects, we shall only present post-filtering aspects due to the space limitation.
As the code structure for handling a single record retrieved by key-based queries is different from that of handling a collection of data obtained by ad-hoc queries, we further divide the post-filtering aspect into two styles: single and collection. Listing 1 shows the code of the PostfilterCollection aspect. Inside the advice, after per-forming the authentication and access checks, it resumes executing the intercepted function, retrieves the query results from the request object and iteratively applies the filter and the field mask to each individual data record. The specific definitions of the constraint expression, filter condition and fields mask are left to concrete aspects that inherit it. The code for PostfilterSingle is very similar yet simpler, since only one data record is being examined.
Figure 2 shows the whole aspect framework and depicts how it works. In sum-mary, to realize a particular access control rule, one has to define a concrete aspect that inherits from a proper abstract aspect, and provide the definitions of pointcut, constraint method, filter condition, and field masking method, if needed.
Fig. 2. The structure and operation of the aspect framework
4 Related Work
Role-based access control (RBAC) [16] is the most often cited guiding principle for application-level security. Since then there are many extended proposals for modeling
4
This is indeed undesirable code duplication caused by the lack of proper advice reuse mecha-nisms is AspectJ. But this issue is beyond the scope of this paper.
…
Struts-based Web Applications Action classes…
…
…
Authentication class Hashtable AAAspect
Authentication Aspect Precheck PostFilter Aspect framework Weaving Weaving Implemented by Concrete aspects Concrete aspects R1: … R2: … … Access Control Rules PWD D C BIO aspects classes Singleton request
166 K. Chen and C.-M. Huang
fine-grained access control. We have role-templates [10], domain-type enforcement [2], content-based [20], team-based [9], and instance-level [11], just to name a few. Basically, they all attempt to base access control constraints on some more detailed relationships among the user, the function requested, and the data to be accessed, as we did here. Context information for access control is investigated in [9] [14] [20].
Our work bears a closer relationship with that of Goodwin et al [11]. First, they used the four-tuple access control rules: [user group, action, resource, relationship], where a set of predefined relationship, as opposed to our general constraint, is defined for each resource type. The major concern is instance-level constraints, no field-level constraint covered, though. Second, they also adopt an MVC-like architecture. The controller intercepts all user commands and queries a centralized manager to make the authorization decision. But they did not consider different authentication types and neither did they use aspect-oriented programming to build their framework.
Applying AOP to security concerns is pioneered by [4] [5]. They also sketched how to build frameworks in AspectJ for handling access control. However, they did not focus on Web applications, and neither did they look into access control modeling in detail as we did. The proposed aspects check the constraint before the attempted access and use per-object stateful aspects. In contrast, we have both pre-checking and post-filtering aspects and use stateless singleton aspects. Hanenberg et al [6] describes some idioms for building framework in AspectJ. Georg et al. [8] studies the use of aspects for modeling security concerns from system analysis perspective.
5 Conclusion and Future Work
Security is attracting more and more concerns in the development of Web applica-tions. However, current practices are not capable of supporting a modular implemen-tation of fine-grained access control for Web applications. In this paper, we have presented a systematic approach to model fine-grained access control requirements and an aspect framework for enforcing such requirements for Struts-based Web appli-cations. Our modeling scheme can satisfy a wide range of requirements with different granularity. By employing AOP and framework technology, we have obtained a highly modular implementation of fine-grained access control and achieved a good balance between reuse and customization. Furthermore, the correspondence between access control rules and associated aspects is direct and hence easy to adapt.
A direction we plan to explore is to prepare the access control rules in a configura-tion file and develop a declarative implementaconfigura-tion scheme. Currently, the access con-trol aspects are manually derived from the rules, which require certain programmatic efforts. We shall investigate a translation scheme to generate the concrete aspects automatically from access control rules. This will lead us toward a more declarative implementation and greatly improve the manageability and maintainability of access control requirements.
Acknowledgements. This work was supported in part by the National Science Coun-cil, Taiwan, R.O.C. under grant number NSC-93-2213-E-004-009.
References
[1] The Apache Struts Web Application Framework: http://struts.apache.org/
[2] Chandramouli, R.: A Framework for Multiple Authorization Types in a Healthcare Application System, 17th Annual Computer Security Applications Conference, Dec. 2001.
[3] DeWin, B., Piessens, F., Joosen, W. and Verhanneman, T., On the importance of the separation-of-concerns principle in secure software engineering, Workshop on the Appli-cation of Engineering Principles to System Security Design, 2002.
[4] De Win, B., Vanhaute, B., and De Decker, B., Building Frameworks in AspectJ, ECOOP 2001, Workshop on Advanced Separation of Concerns, pp.1-6.
[5] De Win, B., Vanhaute, B. and De Decker, B., Security Through Aspect-Oriented Pro-gramming, Advances in Network and Distributed Systems Security, Kluwer Academic, pp. 125-138, 2001.
[6] Hanenberg, S. and Schmidmeier, A., Idioms for Building Software Frameworks in As-pectJ, 2nd AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software (ACP4IS), Boston, MA, March 17, 2003.
[7] Gamma, Helm, Johnson and Vlissides, Design Patterns. Addison-Wesley, 1995. [8] Georg, G., Ray, I., and France, R., Using Aspects to Design a Secure System, Proc. of the
8th IEEE Int’l Conf. on Engineering of Complex Computer Systems. December 2002. [9] Georgiadis, C.K., Mavridis, I., Pangalos, G., and Thomas, R.K.: Flexible Team-based
Access Control Using Contexts, Sixth ACM Symposium on Access Control Models and Technologies (SACMAT 2001), Chantilly, VA, USA, May 2001.
[10] Giuri, L., and Iglio, P., Role Templates for Content-Based Access Control, Proceedings, 2nd ACM Workshop on Role-Based Access Control, Fairfax, VA (October 28–29, 1997), pp. 153-59.
[11] Goodwin, R., Goh, S.F., and Wu, F.Y., Instance-level access control for business-to-business electronic commerce, IBM System Journal, vol. 41, no. 2, 2002.
[12] Kiczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M., and Irwin, J., Aspect-Oriented Programming, in ECOOP '97, LNCS 1241, pp. 220-242. [13] Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W.G.,
Get-ting Started with AspectJ, Communications of ACM, vol. 44, no. 10, pp 59-65, Oct. 2001. [14] Kouadri Mostefaoui, G., and Brezillon, P., A generic framework for context-based dis-tributed authorizations, In: Modeling and Using Context (CONTEXT-03), LNAI 2680, Springer Verlag, pp. 204-217.
[15] Open Web Application Security Project: The Top Ten Most Critical Web Application Se-curity Vulnerabilities. http://www.owasp.org/documentation/topten
[16] Sandhu, R., Coyne, E., Feinstein, H., and Youman, C., Role-Based Access Control Mod-els, IEEE Computer, 29(2):38–47, 1996.
[17] Sun Microsystems, Java Authentication and Authorization Service (JAAS), http://java.sun.com/products/jaas/index.jsp
[18] Sun Microsystems, JavaServer Pages Technology (JSP): http://java.sun.com/ products/jsp/
[19] Sun Microsystems, Java Servlet Technology : http://java.sun.com/products/servlet/ [20] Tzelepi1, S.K., Koukopoulos, D.K., and Pangalos, G.: A flexible Content and
Context-based Access Control Model for Multimedia Medical Image Database Systems. ACM SIGMM Electronic Proceedings, 2001.
On Designing Access Control Aspects for
Web Applications
Kung Chen and Chih-Mao Huang
Department of Computer Science
National Chengchi University
Wenshan Dist., Taipei 106,
Taiwan
{
chenk
,
g9224}@cs.nccu.edu.tw
ABSTRACT
This position paper reports our experience in designing access control aspects for Web applications. In particular, we choose the MVC-based Struts framework as the architectural style of our target applications. Two aspect suites in AspectJ are developed to enforce fine-grained access control in a modular and non-invasive manner. While both suites exhibit good software engineering properties, the first suite cannot guarantee the required conditional execution and the second suite achieves it at the cost of code duplication. We elaborate on the underlying issues of aspect composition and present our preliminary findings from this study.
Keywords
Access Control, Aspect-Oriented Programming, Framework, Web Applications.
1. INTRODUCTION
Application-level access control is a typical instance of crosscutting concerns that aspect-oriented programming (AOP) aims to modularize well. As demonstrated in the pioneering work of De Win [4][5], AOP is a promising approach to handle access control enforcement in a highly modular manner. Here we carry on this line of investigation further. Yet, instead of doing a single case study, we will look into a whole class of applications, namely, Web applications. A major goal of this study is to examine how good the mainstream architectural styles of Web applications can support the aspect-oriented approach to fine-grained access control enforcement. We intend to accommodate a wide range of fine-grained access control requirements while keeping the associated access control aspects as non-invasive as possible to the underlying application structures.
Fine-grained access control constraints usually involve, in addition to the designated function, the specific data contents of a user request. For example, in a B2B E-Commerce site, users from any registered organizations have the permission to execute the “viewOrder” function, but they are allowed to view only orders of
their own organization. This is called instance-level access control constraints [8]. Furthermore, within a data record, certain specific elements, such as credit card number, may have to be excluded from screen view to protect the user’s privacy. We refer to this as field-level access control constraints. These constraints are very common in Web-based E-Commerce applications, yet they have not been addressed in previous work based on AOP.
This position paper reports our experience and findings from this study. We approach our goal through a proper analysis of access control granularity and the architectural patterns of Web applications. The techniques of design patterns and template advice [9] are then employed to design the aspects. We present two aspect suites in AspectJ [2] that can enforce fine-grained access control in a modular and non-invasive manner. The first suite separates authentication aspects from other access control aspects, yet the second one integrates both and forms an aspect framework [17].
While both aspect suites exhibit good software engineering properties, we still encountered some issues of aspect composition during this study. Specifically, the aspects in the first suite have simpler structures, yet they cannot guarantee the required conditional execution. In contrast, those aspects in the second suite achieve guaranteed conditional execution at the cost of code duplication. This motivates us to further study the issues using other AOP tools. We choose the recently released JBoss AOP [11], which supports AOP in plain Java classes. The preliminary findings are not very positive, but they should shed some light on the strong and weak points of the aspect composition mechanisms provided in current AOP languages and tools.
The remainder of this paper is organized as follows. Section 2 set up the context of our work by presenting an analysis of approaches to access control. Section 3 discusses our design considerations and the architectural patterns we require from the underlying Web applications. Section 4 presents the access control aspects and explains why we developed an alternative implementation. Section 5 elaborates on our experience from this study and presents some preliminary findings on composing aspects using JBoss AOP. Finally, section 6 concludes.
AOSD ‘05 Workshop on Software-engineering Properties of Languages and Aspect Tehchnologies (SPLAT 05), Chicago, March 2005.
This work was supported in part by the National Science Council, Taiwan, R.O.C. under grant number NSC-93-2213-E-004-009.
2. CHARACTERIZATION OF ACCESS
CONTROL APPROACHES
Access control, also known as authorization, is a process that determines whether an identified user has the privilege to access certain resources. The step to identify a user is usually called
performing authentication. Hence, in the following discussion, by access control we often include user authentication as part of the process.
Modern application platforms such as J2EE and MS.Net provide a high-level API that abstracts the underlying system-level access control mechanisms and allows application developers to separate access control enforcement from functional code to a certain degree. For example, the Java Authentication and Authorization Services (JAAS) [16] of J2EE provide a programmatic API for enforcing general access control as well as declarative security for conducting straightforward access control through a configuration file.
While sufficient for meeting many common access control requirements encountered in application development, APIs like JAAS cannot fully relieve the problem of code scattering and tangling. Specifically, it is very common that application-level authorization decisions must be based on factors specific to an application’s state, other than simple user identity and roles. Here the declarative security of JAAS cannot help; we have to add calls to JAAS to all business logic where such decisions are needed. As the business logic is spread over multiple modules, so too is the implementation of the access control logic.
To further clarify the issues involved, we present an analysis of access control approaches from two different dimensions. One is granularity level which concerns user requirements; the other is implementation technology adopted by application developers. First, we model the interaction between a user and an application system as a sequence of three-tuples: <user, function, data>, indicating a user’s request to execute the function on a specific data object. The security administrator will specify access control rules with constraints that must be satisfied to grant any access requests based on the attributes of the three elements in the tuple. For example, the following rule demands that, after password authentication, only VIP customers are allowed to execute the createOrder function with total amount argument exceeding $100,000:
<createOrder, AuthType=Password,
(lessEq(Fun.getArgument(“total”), 100000) || defined(User.getAttr(“VIP”)))>
Along the lines of thought we divide the granularity of a system’s access control into three levels: user, function, and data. User-level granularity allows a user to access anything if he or she is a legitimate user, e.g., pass the password check. Function-level granularity restricts a legitimate user’s access to application functions based on the attributes of the user and the function elements, yet regardless of the data contents being accessed. The VIP rule stated above belongs to this category. Data-level granularity is the most fine-grained one that also takes the contents of the data to be accessed into consideration when making the decision. For instance, the following rule dictates that customers can list only orders of their own.
<listOrders, AuthType=Password,
(User.getRoles().contains(“customer”) && equals(User.getName(), Data.getOwner()))>
Access control is a system-wide concern that cut across functional modules. Moreover, to make an access control decision, especially fine-grained ones, the aspect code need substantial information from the application about the context in which the decision is required. It is not something like function tracing that Second, we divide the implementation technologies for access
control into three different levels: hard-wired, adaptable, and
mixed with other functional code. This is quite common in existing systems. In contrast, both adaptable and configurable implementations require that the access control code is properly modularized and can be adapted to new requirements with little efforts. The key difference between them is that a configurable implementation enables us to set the access control rules in a non-programming language, such as XML, and afterwards to revise only the rules to get a different access control setting; while in a highly adaptable implementation, we still need to look into the source code to make the necessary changes [18].
Figure 1: Comparing Access Control Approaches
By combining these two dimensions, we get nine different configurations of granularity and implementation technology for access control. These configurations span a wide spectrum that covers existing systems, security services of modern application platforms, emerging application development technology, and the ideal approach. Figure 1 shows the relative positions of representative approaches based on this framework. Many existing applications fall in the squares of hard-wired implementation, especially in the presence of fine-grained requirements. JAAS allows configurable implementations for simple user-level access control, and supports configurable function-level access control in a very limited context where user attributes such as roles are the only criteria for making the access control decisions1. On the other hand, we will show that, in our study context, AOP can support a high degree of adaptability for all levels of access control. Furthermore, we claim that it is also feasible to derive a configurable implementation for fine-grained using AOP.
3. DESIGN RATIONALE
This section highlights the design rationale behind our access control aspects for Web applications.
3.1 Desiderata
1
This is indicated by the asterisk attached to JAAS in Figure 1.
Implementation tTechnology Granularity Level AOP JAAS* JAAS and existing app AOP JAAS Data Fun User
Hard-wired Adaptable Configurable AOP
Future work
is completely orthogonal to functional modules and all one has to do is define the functions to be traced as the pointcuts without any involvement form the underlying function. In contrast, access control aspects depend on the cooperation from the application to a significant degree. We need to carefully look for the proper application pointcuts to weave in aspect code so that a suitable balance between information need and non-invasiveness is achieved.
This turns out to be more of a challenge. It is often the case that, in order to obtain the needed information, we must take some invasive measures to adapt an application. This seems to be unavoidable, yet we do not plan to invent any new architectural styles for the underlying applications. Instead, we decided to look into the mainstream architectural patterns for Web applications which have proven records and may suit our purpose.
In addition to following current architectural patterns, we set up three criteria for choosing the pointcuts for hooking access control aspects. First, all the information required for enforcing access control rules and filtering out unauthorized contents must be available to the aspect code, since fine-grained access control cannot be realized without detailed application state. Second, in case that the attempted access must be denied, exception propagation and handling must not incur significant impacts on the underlying program structure. The same requirement holds for filtering out unauthorized contents. Third, the correspondence between an access control rule and an enforcing aspect should be direct and clear for management and maintenance purposes.
3.2 Architectural Style Decision
A good starting point for structuring Web application is the three-tier architectural principle of dividing an application into three logical areas: presentation, business logic, and data processing. In the beginning, it is tempting to consider functions inside the business logic tier or the data tier as the proper hook points for the aspects. However, after some investigation, we reached the conclusion that they are not the ideal targets for achieving our objectives. It can easily lead to messy code for passing the required information or handle access denying exceptions. Neither does the internal logic of the presentation tier a good place for handling unauthorized data contents for similar reasons. After some investigations, we choose the well-accepted Model-View-Controller (MVC) [7] architectural pattern as the structural guideline for our Web applications. In MVC, the model components encapsulate the application components in the business logic and data tiers. The view components are those pieces of an application that display the information provided by model components and accept input. The controller is a special program unit that coordinates all the activities of the model and view components. MVC is indeed a very good example of separation of concerns; it not only organizes the presentation tier well but also preserves a clean interface with the business tier. Furthermore, many architectural frameworks for Web applications are based on MVC; this decision would greatly increase the applicability of our approach. Here we adopt the very popular Java-based Apache Struts framework [1] for our study. Figure 2 illustrates the architecture of Struts-based Web applications. Every user request is dispatched to an action class by the controller according to the action mapping defined in the
configuration file, struts-config.xml. These actions are responsible for serving user requests or passing them to the designated business tier components, and for returning the correct view element that the controller should forward to after finishing the user request. This view forwarding is also based on the mapping information specified in the configuration file
.
Figure 2: Struts-based Web Applications
In other words, the action classes play the role of gateway between the presentation tier and the business and the data tiers. Moreover, all action classes must inherit from the class Action and implement an execute method with the following signature. public ActionForward execute
(ActionMapping mapping, ActionForm form, HttpServletRequest req,
HttpServletResponse resp)
We find that the execute method is indeed the proper join point to weave in our advice code for its arguments expose the right information we need. First, user input and any intermediate results, including user authentication records and user profiles, are all stored in the request or session objects, which are available through the HttpServletRequest argument to the method. Therefore, via the args() pointcut, our aspects will have all the information needed for enforcing the access control and filtering out unauthorized contents.
Second, the control transfer between actions and views is specified in the struts-config.xml file, and is realized through the action mapping argument passed to the method and the ActionForward object returned by an action class. Hence we can define proper exception pages in the configuration file and forward to them when an access request is denied in the aspect code. Apparently, this exception handling scheme fits very well into Struts. Third, as will be shown later, an access control rule corresponds to its enforcement aspect quite directly since a user function will usually be supported by an action class.
4. ACCESS CONTROL ASPECTS
This section presents the details of the access control aspects we designed and implemented in AspectJ for Struts-based Web applications. Due to the lack of proper aspect composition
B ro w s e r Controller Access control aspects MVC DB Business tier Data tier Struts-config.xml Request/Session Obj View Model (Action) 3
