Figure 2: UMA infrastructure in SUMA.
users’ point of view, an adaptive and seamless con-
nection of the two access channels results in a univer-
sal access channel to the content. From the content
point of view, a dynamic delivery of adaptive content
results in a universal content presentation to the users.
1.3 Motivation
Let us consider for example a tele-health multimedia
application using Internet to distribute SVG record-
ings (images, videos, and sounds) of doctors and con-
fidential data. Multimedia objects accessed by the ap-
plication users are content unaware and annotations
emptied. Users are equipped with different devices
(PC, Laptop, PDA, Smartphone, etc.). Exchanged
contents have to be adapted to each device profile
using adaptation proxies (they can also add content
like advertisements...). For security and confiden-
tiality reasons, exchanged contents must be authen-
ticated. Moreover some parts of the SVG presenta-
tion appearing in these recordings is highly classified
and should not be changed by unauthorized users (in-
cluding proxies). So the problem here is how can we
allow adaptation operations by intermediaries keep-
ing the authentication and confidentiality of the ex-
changed contents?
Solving such issue using current security tech-
niques and access control models is very hard as the
content is not already defined. In reality, the autho-
rization manager should be able to specify authoriza-
tion rules and policies by stating the features of such
intermediaries.
2 SYSTEM ARCHITECTURE
In this section we describe SUMA (Secure Universal
Multimedia Access) our proxy-based content adapta-
tion framework. The main architecture type of SUMA
system is shown in Figure 3. In this approach, the user
takes the UMA Engine as its proxy, which will then
make the request to the content server on behalf of
this user. The content server response is then received
by the UMA Engine, which afterwards decides and
performs the adaptation (if needed), and then sends
the transformed content back to the client.
The idea is based on the concept of create content
once and used with various presentation. Instead of
preparing different formats for the different devices,
the server use standard SVG files, XML and XSL to
describe Web content and presentation, respectively.
In the proxy side, we find an adaptation engine, im-
plemented with XSLT, and a security engine which
is used to ensure security and authentication of the
exchanged content. To ensure signature validity, the
client has an authenticity verifier which tests the cor-
rectness of the received signature; it is also equipped
with an SVG reader or in the worst case a “adapted
format” reader. In the following we describe each one
of these components.
2.1 Content Authentication Engine
There are three phases available in order to build a se-
cure SVG content to send from the server to a client.
Once a client logs in the system and requests the mul-
timedia data, the server by the Access Control Policy
Generator (ACPG) verifies user’s identification and
the related permission, and generates an adaptive ver-
sion which specifies what parts of the SVG can be
adapted by the intermediary proxy. After that, the ser-
vice provider signs this content using technique de-
scribed in 2.1.2 and sends it to the client passing by
the proxy.
2.1.1 ACPG
In SUMA, access control services simultaneously
support a Role-Based Access Control (RBAC) model
(Ferraiolo et al., 1995) and an access control model
based on Access Control Lists (ACL) (Barkley, 1997).
The RBAC model incorporates a user-role assign-
ment relation, a role hierarchy and a permission-role
assignment relation. Three user-roles are defined
owner, adapter and consumer. The ACL model pro-
vides a straightforward way of granting or denying
access to a given resources for specified users.
The implementation for the prototype of ACPG
has been done using the JAVA Standard Edition.
Therefore, the XACML 2.0 (Anderson, 2004) is cho-
sen to be implemented in the authorization service
using sunxacml1.2 (SUN, 2003). The RBAC poli-
cies and ACL policies have been built using sun’s
XACML APIs. The generated RBAC policies and
ACL policies are shown in Figure 4. An RBAC
XACML PolicySet contain role <PolicySet> (RPS)
and permission <PolicySet> (PPS). The RPS asso-
ciates holders of a given role attribute and value with
a PPS that contains the actual permissions associated
SIGMAP 2007 - International Conference on Signal Processing and Multimedia Applications
332