PREVENTING MALICIOUS PORTLETS FROM COMMUNICATING

AND INTERCEPTING IN COLLABORATION PORTALS

Oliver Gmelch and G¨unther Pernul

Department of Information Systems, University of Regensburg, Regensburg, Germany

Keywords:

Inter-portlet communication, Portal servers, Security policies.

Abstract:

In a “networked enterprise”, distributed teams of partner organizations, humans, computer applications, au-

tonomous robots, and devices are interlinked to collaborate with each other in order to achieve higher pro-

ductivity and to perform joint projects or produce joint products that would have been impossible to develop

without the contributions of multiple collaborators. Within a collaboration, security aspects are of critical

importance. This is in particular true for loosely coupled collaborations in which individual members of one

alliance are working with each other within a certain project only, but may be competitors in other market

ﬁelds at the same time. Going beyond the current state of the art in portal-based collaboration platforms, this

paper presents an approach to prevent unintended information disclosure by malicious portlet instances. The

solution is built on open standards (JSR 286 and XACML) and may be incorporated in collaboration-wide

enterprise portals in order to regulate information ﬂow during inter-portlet communication.

1 INTRODUCTION

Organizations today are confronted with big chal-

lenges such as globalization, shorter innovation cy-

cles or increased competition. One possible remedy

against this situation is forming virtual partnerships

in order to create ﬂexible and agile business networks

between a number of partner organizations having

complementary competencies. As diagnosed by re-

cent surveys performed for instance by AT&T (AT&T

Corp., 2008), a signiﬁcant increase in the number of

business alliances can be expected in the near future.

One of the key challenges in virtual enterprises

is the backing by dedicated information and com-

munication technology (ICT). Identiﬁed as a crucial

characeristic of virtual partnerships, ICT systems are

expected to provide support for different success fac-

tors such as integration on process level across com-

pany boundaries or information integration, implying

provisioning the right information to the responsible

user at the proper point in time (Katzy, 1998).

One way of achieving this information integra-

tion is via the introduction of speciﬁcally-tailored En-

terprise Portals, allowing for integration of different

applications (even from different alliance partners)

in one common user interface comprising a number

of speciﬁcally-crafted portlets (Shilakes and Tylman,

1998). Using communication facilities between these

portlets, the enterprise portal is empowered to apply

context changes in one application to other applica-

tions involved in a speciﬁc setting. While the appli-

cations run independently in the different sites, inter-

portlet communication is necessary at the portal level.

However, security aspects imposed by the communi-

cation of independent applications at varying security

level must not be neglected. For instance, unrestricted

communication may result in unintended information

disclosure, thus posing great risks on conﬁdential in-

formation processed in such settings and resulting in

great loss of acceptance of involved applications or

even a loss of trust in an alliance member or alliances

as a whole.

The research project “SPIKE” (Secure Process-

oriented Integrative Service Infrastructure for Net-

worked Enterprises)

, funded within the 7th frame-

work programme of the European Union, is working

on a portal solution providing tool support for collab-

orations. On the portal level, the SPIKE project also

deals with the need for dynamic evaluation of secu-

rity policies of individual applications based on the

current context of the user. Another major concern is

the potential disclosure of information through mali-

cious portlets.

The goal of this paper is to provide a novel mech-

http://www.spike-project.eu

177

Gmelch O. and Pernul G. (2010).

PREVENTING MALICIOUS PORTLETS FROM COMMUNICATING AND INTERCEPTING IN COLLABORATION PORTALS.

In Proceedings of the International Conference on Security and Cryptography, pages 177-182

DOI: 10.5220/0002990301770182

 SciTePress

anism for secure communication among individual

portlets in order to prevent unintended information

disclosure by malicious portlets. A malicious port-

let can be characterized as hosting an application

which is only trusted to a limited extent, but whose

applications’ functionality cannot be abstained from.

In this context, an approach is presented which tar-

gets at a standards-compliant integration of elements

of the XACML architecture in accordance with the

Java portlet speciﬁcations. Based on this integration,

XACML policies are used to evaluate the distribu-

tion of speciﬁc events in a portal user session to other

portlets deployed on the same page. Using these poli-

cies, it will be possible to exclude malicious portlets

from receiving any but the bare minimum of required

information about other surrounding portlets used in

the same portal session simultaneously, whilst pre-

serving functionality of all other portlet applications.

At the same time, the solution will allow for ﬂexi-

ble changes in portlet communication policies with-

out the need to redeploy the portlets in use.

This paper is structured as follows: Following this

introduction on inter-portlet communication and cor-

responding security requirements, section 2 presents

relevant work related to the topic of both portal sys-

tems and inter-portlet communication. Section 3 then

provides further information about security policies,

which are then further elaborated upon and practically

implemented into the setting of SPIKE in section 4.

Section 5 presents future work of the authors and con-

cludes this paper.

2 RELATED WORK AND

BUILDING BLOCKS

Collaborative software as introduced in section 1 in

most cases is built around a portal system. A rather

technical deﬁnition of the term portal is given in the

Java Portlet Speciﬁcation JSR 168. According to this

speciﬁcation, “a portal is a web-based application that

– commonly – provides personalization, single-sign-

on, content aggregation from different sources and

hosts on the presentation layer of information sys-

tems. Aggregation is the action of integrating con-

tent from different sources within a webpage.” In

the context of Java-based portal servers as employed

by SPIKE, it was identiﬁed a major drawback of

the Java portlet speciﬁcation JSR 168 that individ-

ual portlets running in one portal could not commu-

nicate with each other (Yang and Allan, 2006), whilst

security considerations only were ascribed a subordi-

nated role. Thus, work has been carried out to enable

inter-portlet communication in an extension to JSR

168, focusing on communication between individual

portlets, what is known as inter-portlet communica-

tion. Noteworthy in this context are the works of Bee-

son and Wright (Beeson and Wright, 2005), focus-

ing on the reusability aspects of portlets in Grid-based

environments, including a portable inter-portlet com-

munication mechanism. Moreno et al. also follow

the paradigm of modelling inter-portlet communica-

tion in a provider-independentmanner (Moreno et al.,

2005). Likewise, Priebe et al. introduce the concept

of a communication bus, enabling portlets to publish

their current user context, which can be picked up by

other portlets and used to show related information

(Priebe and Pernul, 2003). Song et al. focus on the

usage of HTML fragments in order to achieve portlet

interoperability (Song et al., 2007).

With the advent of JSR 286 extending JSR 168,

a standardized solution has been made available “to

send and retrieve events and perform state changes

or send further events as a result of processing an

event” (Hepper, 2008). After the occurence of a port-

let event, the event is communicated to the portlet

event broker provided by the portal server, looking up

all registered event types and associated portlets. It is

the portlet event broker that ﬁnally distributes portlet

events to any associated portlet capable of processing

it. Security requirements, however, in the form that

inter-portlet communicationis subject to security con-

siderations, play only a subordinated role. Another

closely related drawback to the inter-portlet commu-

nication solution provided by JSR 286 is its lack of

ﬂexibility. During deployment of a portlet, its com-

munication policy is deﬁned and taken into account

by the portal server afterwards. This way, a mali-

cious portlet, acting as a trojan horse, can subscribe

to all events occuring in the portal session, leading to

the possibility of unintended information disclosure

of potentially conﬁdential information, for instance

about customer or accounting information active in

another portlet instance running within the same por-

tal context. Likewise, the approach imposed by JSR

286 does not consider any potentially available con-

text information – i.e., about the active collaboration

or the current workﬂow. This all leads to the necessity

of security policies deﬁning the allowed communica-

tion behaviour of a portlet in a speciﬁc context.

The area of security policies is widely dominated

by the XACML standard, whose current version 2.0

has been published in 2005 by OASIS (Moses et al.,

2005) with efforts towards release 3.0 ongoing since.

Based on an abstract model as deﬁned by IETF in

(Yavatkar et al., 2000) and (Westerinen et al., 2001)

and ISO/IEC in (ISO/IEC, 1996), XACML provides a

standardized method regarding access control for re-

SECRYPT 2010 - International Conference on Security and Cryptography

178

sources and describes how rules or request/response

messages are to be deﬁned in order to enable dynamic

authorization based on either a set of provided at-

tributes or available context information. Following

a common description of entities and their attributes,

XACML allows for ﬁne-granular access control go-

ing beyond a static permit or deny result, taking into

account runtime aspects of distributed systems.

One great advantage regarding an implementa-

tion of secure inter-portlet communication backed by

XACML is its distributed approach, which enables

separation between policy enforcement and policy

deﬁnition. This is of special importance when used in

distributed environments like collaboration platforms

spanning various sources of software from individual

collaboration members. Hence, it is possible to have

the deﬁnition of a baseline policy per portlet appli-

cation provided by the application itself, which can

then be accepted by the portlet administrator or fur-

ther limited regarding the application’s intended com-

munication behaviour and trust level. Likewise, the

evaluation of aforementioned portlet communication

policies can be performed during runtime, introduc-

ing a greater level of ﬂexibility in comparison to the

approach currently followed by JSR 286-compliant

implementations as outlined in section 2.

Recent activities in the area of policies in combi-

nation with portal systems have mainly focused on the

aspects of achieving a uniform login into portal sys-

tems. A signiﬁcant number of portal solution vendors

is already offering support for XACML-based login

into their systems, for instance in the Liferay portal

server

. Yin et al. have extended the idea of portal

authorization to the employment of web services (Yin

et al., 2007). The idea of federated authentication and

authorization for portal systems in Grid environments

based on the PERMIS framework was ﬁrst presented

by Chadwick et al. (Chadwick et al., 2005) and fur-

ther elaborated by Vullings et al. (Vullings et al.,

2007).

The OpenPortal project strives to provide an open-

source portal server, originally derived from the Sun

Java System Portal Server. As a feature enhancement

to the standard implementation in JSR 286, the port-

let container of OpenPortal server in version 2.0 in-

troduced a portlet policy, governing access to events,

container events and public render parameters (Sun

Microsystems, Inc., 2008). However, the feature re-

mains vaguely documented and so far has not created

further impact onto other projects whilst providing

only limited extensions to the original speciﬁcation

in JSR 286.

In this paper, we will employ the XACML stan-

http://www.liferay.com

Figure 1: XACML architecture for secure inter-portlet com-

munication.

dard in order to provide a mechanism for deﬁnition

and evaluation of security policies in collaboration

settings, imposing restrictions on inter-portlet com-

munication. Based on the portlet standards JSR 168

and JSR 286, a possible solution will be shown.

3 INTER-PORTLET

COMMUNICATION IN PORTAL

SYSTEMS

Since the advent of standardized communication

mechanisms provided by JSR 286-compliant portal

servers, sending and retrieving events between indi-

vidual portlets has been made possible. In this model,

the portlets follow a loosely coupled paradigm with

the portal server acting as a message broker in be-

tween different portlets, distributing the events ac-

cording to the speciﬁcations during deployment of the

individual portlets.

In the portlet conﬁguration ﬁle portlet.xml, com-

munication channels via distinct message types as

provided by individual portlets are deﬁned. Listing 1

shows an excerpt of the conﬁguration of a maps port-

let which is intended to publish information about the

current location in the map via two portlet events, Set-

MarkerEvent and MapBoundsEvent, represented via

two result types containing information about map

search results.

As illustrated in listing 1, severe security limita-

tions occur because the assignment does not take into

account dynamic changes in the context of the portlets

nor does it respect changes due to different users em-

ploying the same applications with differing access

rights. Instead, upon appearance of an event as origi-

nating from one source portlet, the brokering mecha-

nism of the portal server determines the recipients the

event is to be delivered to, based on the static assign-

ments during deployment time.

PREVENTING MALICIOUS PORTLETS FROM COMMUNICATING AND INTERCEPTING IN COLLABORATION

PORTALS

179

<supported-publishing-event>

<qname xmlns:x="http://www.spike-

project.eu">

x:demo.SetMarkerEvent </qname>

</supported-publishing-event>

<supported-processing-event>

<qname xmlns:x="http://www.spike -

project.eu">

x:demo..</qname>

</supported-processing-event>(...)

<qname xmlns:x="http://www.spike -

project.eu">

x:demo.MapBoundsEvent </qname>

<value -type>SPIKEipcDemo .MapBounds</

value-type>

</event-definition>

<qname xmlns:x="http://www.spike -

project.eu">

x:demo.SetMarkerEvent </qname>

<value -type>SPIKEipcDemo .

ResultsWrapper </value -type>

</event-definition>

Listing 1: Portlet conﬁguration.

Also, listing 1 shows the deﬁnition of two

event types, x:demo.MapBoundsEvent and

x:demo.SetMarkerEvent. The tag supported-

publishing-event deﬁnes which events can be

published by the corresponding portlet, in this

case x.demo.SetMarkerEvent. Contrary, the tag

supported-processing-event deﬁnes which events a

speciﬁc portlet subscribes to. In this case, the portlet

conﬁguration uses a wildcard mechanism, implying

the subscription of all events labeled x:demo.*.

Going one step further, this way, all possible events

could be subscribed to by a malicious actor, leading

to a potential loss of conﬁdentiality.

Given a possible subscription of all available inter-

portlet events using the wildcard mechanism as laid

out above, a malicious portlet could try to steal

sensitive information transferred via the inter-portlet

communication mechanism by snifﬁng it and further

transferring it to an attacker’s IT systems. Thus, the

attacker in turn could gain internal information about

a collaboration, associated companies, and processed

data. This knowledge could afterwards be used to

launch an attack, for instance via social engineering.

Likewise, an attacker could remain entirely passive,

collecting as much information as possible.

4 XACML POLICIES FOR

SECURE INTER-PORTLET

COMMUNICATION

To overcome the shortcomings outlined in the previ-

ous section, the XACML architecture is introduced

to the portal event mechanisms as imposed by the

Java speciﬁcation JSR 286, focusing on extensibility

and ﬂexibility when implementing security policies

for portlet communication. Starting from the inter-

portlet communication as imposed by the JSR 286

standard, the authors have introduced elements of the

XACML architecture into the inter-portlet communi-

cation mechanisms of the OpenPortal project

, which

is also used by the Liferay portal server.

As can be seen from ﬁgure 1 which gives a sim-

pliﬁed overview over the integration of the portal

server’s event distribution with an excerpt of the ba-

sic elements of the XACML architecture, the au-

thors have introduced the concept of a policy enforce-

ment point (PEP) into the distribution of inter-portlet

events. After the occurence of a portlet event (step 1),

all portlets in question of receiving the current event

as deﬁned in the global portlet deployment policy are

examined (step 2). For every portlet identiﬁed, the

portlet event broker in turn requests a decision to al-

low or disallow communication of one event between

current source and identiﬁed destination portlet. Ex-

tending the existing portlet event broker of the portal

server, it is the duty of the PEP to enforce the pol-

icy of a speciﬁc source portlet as deﬁned by the portal

administrator (step 3). The PEP in turn requests a de-

cision from the Policy Decision Point (PDP), consid-

ering source and destination portlet, including further

information about the user request, i.e. the user’s por-

tal context, date and time information, and the type

of event to be issued (step 4). For the ﬁnal decision,

the PDP queries for further attributes from the Pol-

icy Information Point (PIP, step 5). After successful

attribute retrieval by the PIP, the policy decision is is-

sued by PDP and returned back to PEP afterwards,

ﬁnally taken into account by the portlet event broker

(steps 6 and 7). Ultimately, the portlet event is deliv-

ered to the portlet treated by the current iteration of

the global list of portlets as initially identiﬁed in step

2 (steps 8.a and 8.b).

With the introduction of policy evaluation during

runtime allowing for context-dependent decisions, it

is yet to be deﬁned what constitutes the context in

a portal session. First and foremost, context infor-

mation should contain information about the user it-

self, i.e. about tasks and roles assigned to that user

https://portal.dev.java.net

SECRYPT 2010 - International Conference on Security and Cryptography

180

<Policy PolicyId="SPIKEipcDemoPolicy " (...)

RuleCombiningAlgId ="identifier:rule -combining -algorithm:

permit -deny -overrides">

<Target >(...)

<Resources><ResourceMatch

MatchId="urn:oasis:names:tc:xacml:1 .0:function:string -equal">

<ResourceAttributeDesignator

AttributeId="urn:spike:names:spike:1 .0:portal:portlet:portletId "

DataType="http://www.w3.org/2001/ XMLSchema#string "/>

SPIKEipcDemo </AttributeValue >

</ResourceMatch ></Resources> (...)

</Target >

<Rule/> (...)

</Policy >

Listing 2: Excerpt of sample portlet communication policy.

in accordance to the alliance the user is currently

working in. Additionally, the user context should

contain company- and alliance-related information as

well. This way, it is possible to deﬁne individual

application-speciﬁc portlet communication rights per

user and per alliance. Individual alliances may have

different security policies, thus treating one portlet ap-

plication in different ways. Likewise, this opens the

opportunity to limit the execution of speciﬁc applica-

tions to a predeﬁned workﬂow. Furthermore, an ap-

plication’s communication behaviour may be limited

according to date and time information. For instance,

communication of a portlet may only be granted in

special time frames, i.e. an application is allowed to

send and/or retrieve events only during the regular op-

erating hours of a company, hence limiting the attack

vector. Apart from these two examples laid out, more

scenarios of potential usage can be thought of by the

use of corresponding policies.

In the implementation, a number of important at-

tributes for usage within portlet communication pol-

icy evaluation has been identiﬁed and collected in

a common SPIKE vocabulary, deﬁning available at-

tributes for policy decisions. Extending the exam-

ple of the SPIKEipcDemo portlet, listing 2 shows

excerpts of a policy deﬁnition in charge of regulat-

ing the portlet’s communication behaviour, beginning

with the speciﬁcation of a rule combining algorithm

as introduced in the following sections. Furthermore,

the deﬁnition of a resource target is shown in list-

ing 2, consisting of the deﬁnition of a ResourceMatch

function, performing a string comparison. The Re-

sourceAttributeDesignator induces comparison of the

attribute portletId as provided by the SPIKE vocabu-

lary with each evaluated portlet’s id parameter, which

is stated in the individual policies generated. Fol-

lowing the deﬁnition of Target, individual rules can

be speciﬁed, matching different criteria as mentioned

above, for instance date and time information, using

the Rule tag, left empty in this example. As poten-

tially conﬂicting interests of service user, platform

provider, and the provider of a service have to be bal-

anced, the matter of combining these individual poli-

cies becomes crucial. With the XACML standard pro-

viding different combination algorithms with regard

to evaluation results of multiple policies, the ordered-

deny-overrides algorithm has proven to be the most

valuable. As security concerns of users of collabora-

tion platforms are to be rated higher than the interests

of providers of both platform and its associated ser-

vices, the user should be able to deny all communica-

tion between individual applications inside a portal.

Using the ordered-deny-overrides algorithm, policies

extracted from the user’s preferences can be put ﬁrst

into the PolicySet generated automatically, meaning

that the user’s policy can block individual event types,

whilst allowing desired communication behaviour as

suggested and described via a service provider’s ser-

vice policy.

5 CONCLUSIONS AND FUTURE

WORK

This paper has shown the necessity for a secure

inter-portlet communication mechanism. Based on a

standard JSR 286-compliant implementation, it was

shown that securing communication between individ-

ual portlets can be achieved easily whilst increasing

ﬂexibility at the same time. Compatibility with exist-

ing solutions being a major goal of the implementa-

tion, the approach presented in this paper focuses on

a minimal-invasive solution with regard to the inter-

PREVENTING MALICIOUS PORTLETS FROM COMMUNICATING AND INTERCEPTING IN COLLABORATION

PORTALS

181

portlet communication mechanism as deﬁned in the

Java speciﬁcation request (JSR) 286.

Future work of the authors is going to be per-

formed in a variety of ﬁelds, based on the work pre-

sented in this paper. First and foremost, the authors

are going to continue the work of thorough inves-

tigation of portal security aspects, predominantly in

the context of virtual enterprises and alliance-wide

application integration. A main cornerstone of fur-

ther research is the combination of different poli-

cies stemming from individual stakeholders, i.e. ser-

vice providers and consumers. Besides, the ques-

tion of runtime performance aspects of the encom-

passed solution is to be investigated in more detail.

Even though inter-portlet communication can only

seldomly be characterised as a time-critical function-

ality to the overall system, it is interesting to perform

deeper analysis on the scalability aspects of portlet

communication policies.

ACKNOWLEDGEMENTS

The research leading to these results is receiving fund-

ing from the European Community’s Seventh Frame-

work Programme under grant agreement no. 217098

and from the European Regional Development Funds

(ERDF). The content of this publication is the sole re-

sponsibility of the authors and in no way represents

the view of the European Commission or its services.

REFERENCES

AT&T Corp. (2008). Collaboration across borders.

http://www.corp.att.com/emea/docs/s5 collaboration

eng.pdf, retrieved 2010-02-26.

Beeson, B. and Wright, A. (2005). Developing reusable

portals for scripted scientiﬁc codes. In Proceedings of

the First International Conference on e-Science and

Grid Computing, pages 502–507. IEEE Computer So-

ciety.

Chadwick, D., Otenko, S., and Welch, V. (2005). Us-

ing SAML to link the GLOBUS toolkit to the PER-

MIS authorisation infrastructure. In Proceedings of

8th Annual IFIP TC-6 TC-11 Conference on Commu-

nications and Multimedia Security, pages 251–261.

Springer.

Hepper, S. (2008). JSR 286: Java Portlet Speciﬁcation Ver-

sion 2.0. Java Community Process.

ISO/IEC (1996). ISO/IEC 10181-3:1996 Information tech-

nology – Open Systems Interconnection – Security

frameworks for open systems: Access control frame-

work. Technical report, ISO/IEC, New York, NY,

USA.

Katzy, B. R. (1998). Design and implementation of vir-

tual organizations. In Proceedings of the Thirty-First

Hawaii International Conference on System Sciences

(HICSS), volume 4, pages 142–151, Los Alamitos,

CA, USA. IEEE Computer Society.

Moreno, N., Romero, J. R., and Vallecillo, A. (2005). Incor-

porating cooperative portlets in web application de-

velopment. In Proceedings of the 1st Workshop on

Model-Driven Web Engineering (MDWE 2005), pages

70–79.

Moses, T. et al. (2005). eXtensible Access Control Markup

Language (XACML) Version 2.0. OASIS Standard.

Priebe, T. and Pernul, G. (2003). Towards integrative en-

terprise knowledge portals. In CIKM ’03: Proceed-

ings of the twelfth international conference on Infor-

mation and Knowledge management, pages 216–223,

New York, NY, USA. ACM Press.

Shilakes, C. C. and Tylman, J. (1998). Enterprise informa-

tion portals. Merril Lynch.

Song, J., Wei, J., and Wan, S. (2007). An HTML frag-

ments based approach for portlet interoperability. In

Distributed Applications and Interoperable Systems,

volume 4531/2007, pages 195–209. Springer Berlin /

Heidelberg.

Sun Microsystems, Inc. (2008). Sun Java System Portal

Server 7.2 Developer’s Guide. Sun Microsystems,

Inc., http://dlc.sun.com/pdf/820-2057/820-2057.pdf,

retrieved 2010-02-22.

Vullings, E., Dalziel, J., and Buchhorn, M. (2007). Secure

Federated Authentication and Authorisation to GRID

Portal Applications using SAML and XACML. In

Journal of Research and Practice in Information Tech-

nology, volume 39, pages 101–114. Australian Com-

puter Society Inc.

Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,

Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,

J., and Waldbusser, S. (2001). RFC3198: Terminol-

ogy for Policy-Based Management. Technical report,

IETF.

Yang, X. and Allan, R. (2006). Web-based Virtual Research

Environments (VRE): support collaboration in e-

Science. In Proceedings of the 2006 IEEE/WIC/ACM

international conference on Web Intelligence and In-

telligent Agent Technology, pages 184–187. IEEE

Computer Society Washington, DC, USA.

Yavatkar, R., Pendarakis, D., and Guerin, R. (2000).

RFC2753: A Framework for Policy-based Admission

Control. Technical report, IETF.

Yin, H., Zhou, J., Wu, H., and Yu, L. (2007). A SAM-

L/XACML Based Access Control between Portal and

Web Services. In Proceedings of the The First In-

ternational Symposium on Data, Privacy, and E-

Commerce, pages 356–360. IEEE Computer Society

Washington, DC, USA.

SECRYPT 2010 - International Conference on Security and Cryptography

182