Visual Computer- Managed Security - IEEE Computer Society

Feature: Software Security

Visual ComputerManaged Security:

A Framework for Developing Access Control in Enterprise Applications Massimiliano Giordano and Giuseppe Polese, Università degli Studi di Salerno

// The Vicoms framework assists programmers in coding access control in Java applications, providing transparent management of security aspects in enterprise level applications, including legacy ones. //

In component-based systems, the application server is a container for security mechanisms that govern access to application functionalities. Container-managed security (CMS), such as that developed for the Java Enterprise Edition (JEE) architecture, can

enable or inhibit access to a resource or a service, but it can’t address more fine-grained aspects of access permissions. For instance, if an e-learning platform has two registered roles, student and instructor, CMS would only allow specification of the resources

62 I E E E S o f t w a r e | p u b l is h e d b y t h e I E E E c o m p u t e r s o c ie t y 

that each role can or can’t access, but it wouldn’t allow restricting a student access to a resource to a given number of times or time interval. So in these cases, the developer must hard code security rather than using CMS. This represents a fundamental limitation in the JEE access-control mechanisms that constrains its usefulness in applying advanced security mechanisms to industry applications. Furthermore, standard security in the JEE architecture is declarative. Information about an application’s security configuration is located in the deployment descriptor, a file external to the application. If security mechanisms aren’t hard coded in the software components, developers can set security policies during application deployment, without needing to modify the component source codes. But in situations where declarative security isn’t sufficient to achieve proper security control, developers might need to manually add source code to acquire security information from the container, even though the information is limited to the user and his or her security role. This security implementation strategy is time-­ consuming, and the provider of the container’s business logic must have excellent knowledge about security mechanisms as well as the security policy the application must satisfy. Some JEE product providers extend the security functionalities of their application servers, but this keeps applications that utilize new features from being portable to other application servers, and software components are mostly not reusable. Neither declarative nor programmatic security support cooperation with application servers other than JEE servers. We have developed the Visual Computer Managed Security 0 74 0 -74 5 9 / 13 / $ 3 1. 0 0 © 2 0 13 I E E E

http://server.example.com/code/docs/developer-guide.html Figure 1. Listing fragment of an XACML policy. The code specifies the subjects, resources, and actions to which the given role-based access-control (RBAC) policy applies.

(Vicoms) framework to assist programmers in the specification of complex access-control policies for JEE software at the application-server level. Vicoms exploits principles of visual languages and aspect-oriented programming (AOP) to specify finegrained access-control policies.1,2 It relies on an integrated development environment (IDE) and an application server to give programmers a complete environment for writing enterprise-level applications and a fully declarative way of specifying security aspects with the application server. We’ve used the Vicoms framework in open source software, such as the Eclipse IDE and the JBoss application server, but the approach can be easily adopted in other contexts. Vicoms is based on the JEE architecture, JBoss 3.0 application server, AspectJ 1.1 visual programming language, Java Authentication Authorization Service API, and OMG’s Resource Access Decision Facility. 3

Vicoms Security Concepts and Techniques As background to the Vicoms framework, we describe concepts useful for managing access control in JEE applications.

XACML The Extensible Access Control Markup Language (XACML) is extremely flexible for expressing access-control policies in large-scale distributed environments.4 It’s an XML-based language, or schema, conceived to create access policies, automate their use in managing access control for generic devices, and support interaction among different systems and frameworks. XACML was designed to replace existing application-­specific, proprietary accesscontrol mechanisms, and it’s supported by major companies such as Axiomatics, Boeing, NextLabs, Quest Software, and Oracle.5 The XACML specification describes a request/response language for

both expressing and answering queries about whether to allow a particular access and an access-control policy language that lets developers specify who can do what and when. Figure 1 shows an XACML fragment specifying the subjects (users, groups, and roles), resources (applications, services, and digital contents), and actions (access to resources, operations on resources, and so forth) to which a given policy applies. 6 It also suggests the complexity of using XACML directly to specify rolebase access control (RBAC) policies and the need for visual-language-based tools to simplify the task.

AOP for Security AOP is a relatively new programming paradigm,7 which grew out of limitations in object-oriented (OO) and earlier programming paradigms. It enhances modularization by supporting programmers in the separation of concerns, which entails structuring a program into pieces of code with reduced

S e p t e m be r /O c to be r 2013

| IEEE

S o f t w a r e  63

Feature: Software Security

intersection of functionalities. However, some concerns aren’t easily encapsulated within single software modules because they’re shared by different program modules. These are called crosscutting concerns. Access control is a typical crosscutting concern, because it affects several modules of a software

ages of compiled classes, such as in the case of legacy code. More specifically, in AspectJ an aspect is a type that crosscuts a program structure. It contains information typically found in a class—for example, data members and methods—in addition to behavior that’s

AOP simplifies the separation of crosscutting concerns by moving them into separate and independent modules.

vironments. Thus, AOP appears suitable in the context of Cobol, C, PL/1, and so on. There have been many efforts to develop AOP languages for legacy systems, and the market includes many frameworks capable of extending procedural languages such as Cobol and C with AOP constructs. So it’s not difficult to imagine that the framework we present here could be implemented not only for Java based applications but also for systems developed in C, Cobol, and other languages.

Access Control system. Crosscutting concerns have also been used to modify the availability of applications with AOP. 8 When facing crosscutting concerns that don’t walk nicely along the lines set out by structures such as inheritance and association, OO programming degrades to the procedural programming style it ought to replace. In AOP, however, aspects contain this extra complexity in a module of its own and reroute any interface interactions exposed by the base program to this module and back. More formally, aspects let us quantify (through pointcuts) which events (join points) in a program’s flow interest us and what should happen at those points (advices). AspectJ enhances the Java language with aspect features, such as the possibility to define events in a program’s execution (pointcuts) and actions (advices) that execute at join points picked out by a pointcut. AspectJ also allows classes and their hierarchies to be modified by adding new members, altering the inheritance relationship between classes. Moreover, it allows aspects to affect both source code and compiled classes. The latter is extremely important if we want to apply aspects to components that are pack-

executed at a specified point in a program’s execution. AOP simplifies the separation of crosscutting concerns by moving them into aspects, which are separate and independent modules. The OO paradigm allows the separation of concerns that can be mapped to concrete objects, but it can be hard to separate more abstract and complex system properties that cut across other system components. Access control is an example of such a concern. Aspects let programmers precisely and selectively define objects, methods, and events to which access control should be applied. Moreover, the code implementing access control is separated from the implementation of components’ business logic. Implementing security for JEE applications with AspectJ enables the use of containerprovided functionalities as well as any functionalities available in external security library. Finally, although AOP offers a programming paradigm suitable for handling security in legacy systems, the term “legacy” doesn’t necessarily mean a system developed with an OO programming language. AOP has rarely been applied outside of OO, but none of the commonly known crosscutting concerns are inherently tied to OO en-

64 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r e

In container-managed and declarative types of security, the container decides whether a user can access a given service. The decision is based on an application descriptor. In particular, the container allows the principal to identify the client, its security roles, and the roles required to get access to a service. It doesn’t allow access control to be based on a method’s parameter values, the time of the day, or the caller’s physical location. In the last case, you could apply programmatic security and use some limited security information provided by the container, but then you must hard code access control inside the component. By exploiting AspectJ and AOP, the code for access control stands apart from the rest of the application. Any change to the security mechanisms would only require a modification in the aspect code, whereas the application code would remain untouched. In addition, changes to existing security mechanisms won’t require modification to source code components, because only a single aspect will be changed.

The Vicoms Framework Figure 2 shows the framework’s main components. In particular, the Virbac editor, which is a plugin of the Eclipse IDE, provides an extended RBAC editor

to let designers visually define RBAC policies with live entities collected from the application server.7 The application server stores all security policies as well as a Policy Decision Point (PDP), which evaluates access requests against policies, allowing or denying access, and a Policy Enforcement Point (PEP), which enforces such decisions. For legacy code not written with policy-based access control in mind, the application server will use AOP to deviate the program flow to issue access requests to the PDP and continue the execution-based on PDP responses. This process requires no modifications to the source code. In Vicoms we can design and deploy global policies that are independent from a specific platform. The basic idea is to replace embedded security code with external rules, which are usually harder to define and modify. Usually, when developing a system from scratch with access control in mind, subjects, resources, and actions are well defined because the requirements analysis and the internal representations are well known. In our approach, we don’t know this kind of information

Design

Eclipse platform Visual policy editor plug-in (Virbac)

JEE application server

Policy repository

Policy Decision Point (PDP)

Policy Enforcement Point (PEP)

Figure 2. The Vicoms architecture. The Virbac visual policy editor is an Eclipse plugin for specifying RBAC policies with live entities collected from the application server.

in advance, so we try to exploit JEE container facilities and AOP to obtain these entities at runtime, by polling the application or the application server. In particular, through a driver-based model, Vicoms queries the application

Design

server searching for users and roles, and analyzes code structure to find a set of resources and actions, which are then proposed to the user, who can choose the right mapping between entities, resources, and actions.

Design

Actions

Visual-to-textual conversion

Users

XML-based intermediate representation

XML-based intermediate representation

XML-based intermediate representation

Resources XACML translation Application server XACML PolicySet

XACML PolicySet

Policy repository

Figure 3. The Vicoms policy life cycle. The developer acts at the top tier by visually manipulating actions, users, and resources. The system manages the transformation of this high-level specification into a storable policy.

S e p t e m be r /O c to be r 2013

| IEEE

S o f t w a r e  65

Feature: Software Security

Policy

Virbac

Policy

PDP

Policy repository XACML request/response

Access denied/allowed Access request

PEP

Client Figure 4. Visual role-based policy management scenario. A Policy Enforcement Point (PEP) invokes a Policy Decision Point (PDP) to make an access decision, and PDP makes a decision based on the stored policies. XACML is the language used for intermodule communication of both requests and decisions; it’s also used to represent access control policies.

Vicoms Policy Life Cycle

Vicoms Security Specification

Figure 3 summarizes the Vicoms policy life cycle. First, a driver specific to the application server is used to achieve a connection. Next, subjects, resources, and actions are collected from the application server to enable users to visually design specific policies. Finally, user-defined security diagrams are translated into RBAC-XACML code and deployed to the server, which will use AOP to enforce the specified policies. Figure 4 depicts the Vicoms usage scenario. When the end user attempts to access services and resources from a client, Vicoms generates a request. Then, a specific PEP intercepts the request and sends it to the PDP in the form of an authorization decision request. The PDP evaluates it against the stored policies, producing an authorization decision that’s returned to the PEP responsible for the requested resource. In other words, the specific PEP is responsible for enforcing the decision to release the required resource or service, so each service provider must bind the service to the corresponding PEP.

The Vicoms framework accomplishes security specifications in three main phases. Security Diagram Design. Figure 5 shows an example of diagram used in Virbac for visual policy specification. Virbac collects visually manipulable subjects, resources, and actions by polling the application server. Once the user completes the specification of the security diagrams, Vicoms automatically generates XACML-RBAC policies from them. Polling Subjects, Resources, and Actions. The communication between Vi-

coms and the application server is managed by the connection driver, which relies on platform-specific interfaces to perform basic policy-management operations. The connection driver helps the Vicoms editor read subjects, resources, and actions. Moreover, it enables the system to acquire policies, supporting the creation, deletion, and modification of existing elements. Finally, it supports

66 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r e

safe communication protocols to protect systems from intrusion, and digital signature based on strong cryptography to ensure authenticity. Policy Generation. A basic principle in transforming a user-defined RBAC policy view into an XACML policy is not to change the policy semantics during the mapping process. This has a twofold meaning. One is that the attribute restrictions defined in the policy view can’t be lost, and the other is that the logical relations between the attribute restrictions can’t be changed. Moreover, to ensure good validating efficiency of the XACML policy, the attribute restrictions in the visually specified policy should be reasonably distributed in the and elements of the generated XACML policy, which becomes a main problem during the policy translation. For instance, in the XACML policy template, although both and could contain attribute restrictions, their structures and functions are different. In other words, when making a decision on a request, is used for choosing the policies or rules that are pertinent, whereas contains complex Boolean expressions that are used to verify whether access can be granted on the basis of the policies selected with . Because complex expressions will decrease the validating efficiency of a policy, should contain attribute restrictions on the policies’ applicability. This not only avoids unnecessary validation but also reduces the expression’s complexity, thereby improving the policy’s validating efficiency. For example, if a resource can only be accessed within a given time interval, placing this constraint in considerably restricts the number of applicable policies. Our approach first classifies attri-

bute restrictions of the visual policy according to their syntax and semantics. This lets us detect types of restrictions suitable to the element, whereas the remaining restrictions are linked by AND operators and put in the element.

Case Studies We’ve used Vicoms in several research and industrial systems. In particular, we used it to add access-control functionalities for a video surveillance system and to add RBAC within the Adams (Advanced Artefact Management System for software development).9 In addition, we used Vicoms in the context of the Tacamp (Textile/­ Clothing Industry in Campania) project, a big industrial project regarding the use of several advanced information technologies to extend an enterprise information system supporting fashion company activities. Figure 6 shows one of the project’s deployment diagrams. It’s a complex distributed system with functionalities and access-control policies that are expected to evolve over time. A hard-wired access-control implementation within the system modules would be too complex to maintain because it would require continuous interventions on the code and complex checks for verifying policy consistency across different modules. By contrast, our approach provides a centralized management of access-­ control policies at the application-­ server level. So when new accesscontrol needs arise, we only need to visually modify a centralized version of access-control policies, and the system automatically generates changes within the application server. Finally, we used Vicoms to extend the functionalities of a healthcare information system (HIS) developed by a major software firm specialized in medical information systems. HISs involve several roles acting on the sys

Figure 5. A Virbac definition of permissions for the unregistered user role. The user completes the specification of the security diagrams, and Vicoms automatically generates XACML-RBAC policies from them.

tem to perform various operations. For the sake of simplicity, we focus here on the receptionist role, which includes several operations on the system, such as managing patient registration, scheduling patient appointments and hospital admissions, and filing medical records. Although these rules aren’t particularly complex, using OO to implement this access-control model into the HIS model isn’t straightforward. To support user identification, we must add authentication functionalities to the model. In addition, for the actual access checks, most operations must be modified to support access control. Implementing such access-control model with AspectJ is much more effective, as shown in Figure 7. The first aspect, RoleMgr, is responsible for storage and initialization of the HIS roles. The AOP’s keyword perthis specifies that for each instance of the class HISUnit,

a different instance of the RoleMgr aspect will be created. As such, every unit will be accompanied by an owner attribute, which is initialized by the after advice when the unit is created. The Authentication aspect is used to authenticate persons, so it replaces the login() method introduced for the OO access-control implementation. To represent the current user role, the Authentication aspect includes an attribute and an operation to initialize it. Finally, the Authorization aspect implements the actual access control. Here, an around advice verifies the equality between the owner role of the unit that’s currently being accessed and the currentRole, as identified through authentication, and it acts accordingly. In this aspect, the restrictedAccess pointcut specifies the places to enforce this verification. The AOP solution’s integral modularization has many advantages. First,

S e p t e m be r /O c to be r 2013

| IEEE

S o f t w a r e  67

Feature: Software Security

System monitoring

Web services client

SNMP/JMX

Web browsers

SOA/WSDL

Inbox alerter

HTTP

JEE server

RSS

Single sign on Services/ UDDI

Runtime/ solution repository

JSP, servlets, portlets Navigation components Solution engine

Node 2

Application integration

Auditing

Scheduler

Dashboard KPIs

Data mining

Pivot views

Others

Analytic view

Audit reports

Workflow Reporting Inbox

Workflow engine

OLAP engine

Audit repository

Rules engines

Reporting engine

Scheduler JMS

Scheduler repository

Business rules

Workflow repository

Data sources

ETL: Extract, transform, load KPI: Key performance indicator

Data mart Application integration/ETL

Data mining repository

Application data

Business intelligence core components Third-party technology Tacamp applications or data

Figure 6. A deployment diagram of the Tacamp project. Vicoms makes it easy to understand the complex relationships between roles/access-control policies and key functionalities. Policies and functionalities evolve continuously, so a hard-wired implementation of access-control policies would have been inadequate.

coping with changes, especially unanticipated ones, is easier because all relevant code is gathered in one place.

Second, it scales better when the application’s size increases. Third, developers can concentrate on the core prob-

68 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r e

lem without having to worry about side issues, such as code consistency in the case of invasive security-related changes. Finally, the complete separation of concerns makes it easier to understand which security measure is implemented and at which point it’s activated (where and when) Let’s suppose that the HIS is used by a company that defines different participating roles, such as secretaries, managers, and so forth. The original design must be changed to reflect the different roles (which can be done introducing a new class hierarchy for all the available user roles). The accesscontrol subsystem might also require an update. For instance, if secretaries require full access to all information of the clinician they work for, this update will affect all access-control checks. In an OO security solution, these checks are spread over different operations in different classes. This extension results in a lot of work for the programmer, not to mention the increased chances of making mistakes. However, in our Vicom’s aspect-oriented implementation, the only required change is to modify the condition in the if-statement within the Authorization advice so that it includes this new access rule. Such required changes are more local and are performed automatically, considerably relieving the programmer’s work. This example of changing the access-­ control model clearly demonstrates the flexibility gained by AOPs advanced modularization capabilities.

I

mplementing security with AOP allows a more flexible and extensible solution than CMS. Creating a separate module to provide security and weave it into the nonsecured applications requires no modification of application’s source code, although it still requires programming skills. The Vicom framework and Virbac

References 1. S.K. Chang et al., “Visual Authorization Modeling in E-commerce Applications,” IEEE MultiMedia, vol.10, no. 1, 2003, pp. 44–54. 2. M. Giordano et al., “A System for Visual RoleBased Policy Modelling,” J. Visual Languages & Computing, vol. 21, no. 1, 2010, pp. 41–64. 3. Resource Access Decision Facility Specification, Object Management Group, 2001; www.omg.org/docs/formal/01-04-01.pdf. 4. eXtensible Access Control Markup Language (XACML) Version 1.1, Organization for the Advancement of Structured Information, 2003; www.oasis-open.org/committees/ download.php/2406/oasis-xacml-1.0.pdf. 5. “OASIS, Eleven Companies Demonstrate Support for KMIP and XACML OASIS Standards at RSA Conference,” press release, 2012; www.businesswire.com/news/ home/20120227005293/en/Eleven -Companies-Demonstrate-Support -KMIP-XACML-OASIS. 6 A. Anderson, XACML Profile for Role Based Access Control (RBAC), Organization for the Advancement of Structured Information, 2004; http://docs.oasis-open.org/xacml/ cd-xacml-rbac-profile-01.pdf. 7. G. Kiczales et al., “Aspect-Oriented Programming,” Proc. 11th European Conf. ObjectOriented Programming, (ECOOP 97), Springer, 1997, pp. 220–242. 8. F. Cuppens, N. Cuppens-Boulahia, and T. Ramard, “Availability Enforcement by Obligations and Aspects Identification,” Proc. 1st Int’l Conf. Availability, Reliability and Security (ARES 06), IEEE CS, pp. 229–239. 9. A. De Lucia et al., “ADAMS: An ArtefactBased Process Support System,” Proc. 16th Int’l Conf. Software Engineering and Knowledge Engineering (SEKE 04), Knowledge Systems Institute, 2004, pp. 31–36.

aspect RoleMgr perthis(this(HISUnit)) { String role; // the user role after(): execution (HISMgr.new(..) ) { role = Authentication.getRole(); } } aspect Authentication() { static String currentRole; //one per system static String getRole() { if(currentRole == null) currentRole = ; return currentRole; } } aspect Authorization() { point cut restrictedAccess(): execution(* Request.action()); void around():restrictedAccess() { if( if(!OwnerManagement.aspectOf( thisJoinPoint.getThis()).owner. equals(Authentication.getRole())) System.out.println(“Access Denied!”); else proceed(); }

} Figure 7. Access-control aspect implementation. Notice the clean modularization of this AOP-based solution.

About the Authors

tool considerably reduce the required programming skills by using visual languages, CMS, and aspect-oriented security.

Massimiliano Giordano was a research fellow in computer science in the University of Salerno’s Department of Mathematics and Computer Science at the time he performed the work reported here. His research interests include access control, data mining, data visualization, and human computer interaction. Giordano has a PhD in computer science from the University of Salerno. Contact him at giomas74@ gmail.com.

Giuseppe Polese is an associate professor in the University of

Salerno’s Department of Management and Information Technology. His research interests include visual languages, databases, Web engineering, and multimedia software engineering. Polese has a PhD in applied mathematics and computer science from the University of Salerno. Contact him at [email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

S e p t e m be r /O c to be r 2013

| IEEE

S o f t w a r e  69