Scholarly article on topic 'Security Enforcement for Multi-Cloud Platforms – The Case of PaaSage'

Security Enforcement for Multi-Cloud Platforms – The Case of PaaSage Academic research paper on "Computer and information sciences"

Share paper
Academic journal
Procedia Computer Science
OECD Field of science
{cloud / security / authentication / authorisation / model-driven / identity / policies / permissions / roles / users / meta-model / SAML}

Abstract of research paper on Computer and information sciences, author of scientific article — Kyriakos Kritikos, Tom Kirkham, Bartosz Kryza, Philippe Massonet

Abstract Multi-cloud adaptive application provisioning promises to solve the vendor lock-in problem and lead to optimizing the user re- quirements through the selection of the best from the great variety of services offered by cloud providers. As such, various research prototypes and platforms attempt to support this provisioning type. One major concern in using such platforms comes with respect to security in terms of improper access to user personal data and VMs as well as to platform services. To successfully address this concern, this paper proposes a novel model-driven approach and architecture able to secure multi-cloud platforms as well as enable users to have their own private space. Such a solution exploits state-of-the-art security standards and secure model manage- ment technology. This solution is able to cover different security scenarios involving external, web-based and programmatic user authentication.

Academic research paper on topic "Security Enforcement for Multi-Cloud Platforms – The Case of PaaSage"


Available online at


Procedía Computer Science 68 (2015) 103 - 115

HOLACONF - Cloud Forward: From Distributed to Complete Computing,

Security Enforcement for Multi-Cloud Platforms - The Case of


Kyriakos Kritikosa*, Tom Kirkhamb, Bartosz Kryzac, Philippe Massonetd

aICS-FORTH, Heraklion, Crete, Greece bSTFC, United Kingdom cAGH, Krakow, Poland dCETIC, Belgium


Multi-cloud adaptive application provisioning promises to solve the vendor lock-in problem and lead to optimizing the user requirements through the selection of the best from the great variety of services offered by cloud providers. As such, various research prototypes and platforms attempt to support this provisioning type. One major concern in using such platforms comes with respect to security in terms of improper access to user personal data and VMs as well as to platform services. To successfully address this concern, this paper proposes a novel model-driven approach and architecture able to secure multi-cloud platforms as well as enable users to have their own private space. Such a solution exploits state-of-the-art security standards and secure model management technology. This solution is able to cover different security scenarios involving external, web-based and programmatic user authentication.

© 2015 TheAuthors.PublishedbyElsevierB.V.This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of Institute of Communication and Computer Systems.

Keywords: cloud; security; authentication; authorisation; model-driven; identity; policies; permissions; roles; users; meta-model; SAML

1. Introduction

Nowadays more and more organisations move to the cloud due to its various advantages, including cost reduction and adaptive application provisioning to address increasing customer load by exploiting the infinite resources available. Moreover, various proprietary and free platforms have been developed for cloud-based application management.

However, current platforms cannot cater for addressing three main issues: (a) non-optimisation of application deployments; (b) vendor lock-in; (c) completely addressing the security aspect. In fact, the last two issues constitute some of the main factors preventing migration to the cloud.

To confront these issues, the research trend moves towards enabling multi-cloud application management which surely avoids vendor lock-in and enables the optimisation and adaptive provisioning of applications in multi-clouds

* Corresponding author. Tel.: +30-2810-391642 ; fax: +30-2810-391638. E-mail address:

1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of Institute of Communication and Computer Systems. doi: 10.1016/j.procs.2015.09.227

by exploiting the great variety of services offered across different cloud providers. Such a trend is revealed via recent publications and the acceptance of European research projects activated in this research area.

To support the partial automation of the multi-cloud application lifecycle, some of the aforementioned projects follow a model-driven approach. This is true for the PaaSage project which has developed a particular and extensive domain specific language (DSL) called CAMEL1 covering various aspects, including the deployment, provider, organisation, metric and scalability ones. In this project, to also address the security aspect, a security sub-DSL1,2 has been generated while a respective plan reasoner3 has been developed optimising application deployments by considering security requirements at both the higher and lower level in form of security controls and service level objectives (SLOs), respectively.

However, apart from ensuring a certain security level for applications, there is also a need to secure the personal content of organisations in any multi-cloud platform as well as the access to platform services. Such a need is covered by the solution proposed in this paper which provides an authentication and authorisation layer on top of the databases and services offered by the PaaSage platform. This solution caters for generating personal information spaces for organisations and their users, allowing for multi-tenancy. It also suits different access control scenarios including external, programmatic and web-based user authentication. Apart from these benefits, the proposed solution offers an administration API enabling each organisation's administrators to manage the organisation security-oriented information, mainly in the form of organisation policies dictating which organisation roles must have access to which platform services and which part of the private organisation information space in the platform.

The rest of the paper is structured as follows. Section 2 provides background information about PaaSage and its security-oriented meta-models. Section 3 analyzes our solution's architecture. Section 4 provides important details about security-oriented information integration and presents the administration API. Section 5 reviews related work. Finally, Section 6 concludes the paper and draws directions for further research.

2. Background

2.1. PaaSage Architecture

The model-driven deployment approach in PaaSage relies on the extensive CAMEL DSL capturing many aspects in multi-cloud application life-cycle, including requirement, deployment, scalability, and organisation aspects. This approach relies on a particular architecture, shown in Figure 1, involving components belonging in three main modules: Upperware, MetaDataDataBase (MDDB) and Executionware. The main functionality of these three modules is analyzed below along with details about particular components required for explaining in Section 3 our security solution.

The Upperware manages user requirements and application profiles and their mapping to concrete deployment plans. It is also responsible for globally adapting an application's deployment to close the design-time adaptation loop. The Executionware executes concrete application deployment plans while also monitors the application and locally adapts its deployment, thus closing the runtime loop, by executing scaling actions in terms of scalability rules. MDDB is the medium for model-based communication between Upperware and Executionware components. It offers an API for the management of models, including their persistency, sophisticated querying, and the publication of events mapping to their updating. MDDB also enables the derivation of added-value facts via employing a Knowledge Base.

MDDB relies on CDO 1 technology enabling EMF model management and persistence. This technology comes with particular features like transactionality, lazy loading, fault-tolerance, and scalability. It also exploits various underlying database management systems for model persistence. The abstraction over these systems comes with the CDORepository, a model store offering an API through which models can be manipulated. On top of the CDORepos-itory lies a CDOServer accepting requests from CDOClients to perform model-based management actions. In this respect, a CDOClient is an internal component of any other (PaaSage) module or component requiring to manage models over a certain CDORepository.


Fig. 1. The PaaSage platform architecture

Two main entry points exist for users to exploit the facilities of the PaaSage platform. The Service Point (SP) is a REST service which enables accessing the platform services offered allowing users to run the PaaSage adaptive provisioning workflow such that their applications are deployed, executed and adapted. As such, SP lies on top of the three PaaSage modules taking control over the respective execution of their components based on the provisioning workflow.

The Social Network (SN) as well as external UIs or IDEs also consitute entry points in the platform enabling users to perform particular tasks. SN is a web-based medium via which users can execute the PaaSage workflow (via the SP) as well as share knowledge about the cloud. To support such knowledge sharing, apart from providing well-known social network facilities, the SN offers graphical interfaces visualizing analysis results over application execution history, allowing users to discover interesting deployments for their application or similar applications. The SN also allows users to load or export models from MDDB as part of the knowledge sharing experience.

External UIs or IDEs represent alternative and customized entry points for users. They can be considered as external services fitting into the platform in order to provide added-value support to the user (e.g., in the form of billing, knowledge and information analysis or model editing services). To this end, it is more than expected that such components will offer at least the capabilities to manipulate models as well as run PaaSage provisioning workflows.

2.2. Security-Oriented Meta-Models

Two main security-oriented meta-models have been produced as part of the CAMEL DSL focusing on different security aspects. The security meta-model addresses the specification of security requiments and capabilities, while the organisation meta-model captures security-oriented information about organisations covering organisation security policies, users and roles. As this paper contributes to supporting user authentication and authorisation in the PaaSage platform, only the second meta-model is relevant and thus analyzed in more detail below.

2.2.1. Organisation Meta-Model

The main goal of the organisation meta-model is to cover the specification of various organisation-specific information which can be exploited by the PaaSage platform for various tasks, including authentication, authorisation and cloud deployment. This meta-model actually extends the CERIF standard4, used for modelling research organisations, users and roles, across particular aspects. To conform and further support this standard, specific transformation code has been produced to map CERIF models to CAMEL organisation ones. In this way, organisations do not need to generate from scratch their organisation models but rely on existing specifications described in CERIF.

B DataCenter

U PaaSageCredentials

□ CloudPro vider

□ Externa/Identifier [0..*] exte naUdenb fiers

□ CloudCredentials

n ResourcePattern

J InformationResourceFilter

U ServiceResourceFilter


3 User


[1.1] resourc

[1-1] r

[1-1] ro

^ Credentials

Fig. 2. The CAMEL's organisation meta-model

Figure 2 depicts the organisation meta-model which, at the root level, enables specifying an organisation model pertaining to a specific organisation or cloud provider. Cloud providers are represented by a sub-class of Organisation devoted to capturing generic features of a cloud provider organisation, such as the cloud service types offered. By representing cloud providers as organisations, we enable the participation of their users in the PaaSage platform, thus allowing for dynamically updating provider specific models (explicating the cloud services offered) in CAMEL specified via the provider meta-model5, when new cloud services or existing ones are modified, as well as for exploiting the PaaSage platform facilities to adaptively provision applications in their cloud infrastructure.

The organisation meta-model captures basic organisation information in the form of name, email and web address. For cloud provider organisations, further organisation information is specified through an association to the respective cloud-specific provider model as well as the description of own infrastructure in terms of data centres. The latter information can be beneficial as it can allow correlating cloud offerings to data centres and determining certain specificities pertaining to such a correlation in terms of different prices and levels of service or security capabilities.

An organisation model also includes the specification of roles and users. Roles map to particular entity types associated to a set of security policies which are specified in the form of access control permissions (further analyzed in Section 4). Users can have many roles and as such, they inherit the permissions specified for these roles. The mapping from roles to users is specified via role assignments which include important information, such as when the assignment started and when it finishes. Such information can allow a security system to check when roles are not any more attributed to users so as to deny access to such users for resources whose access maps to policies specified for these roles. It can also be exploited to check abnormal behaviour not prevented from the security system, thus enabling to remedy it to the possible extent.

The specification of users includes information pertaining to their own (last and first name or email) and PaaSage platform identification features (in the form of a user login/name). A user is also associated to two different types of credentials: (a) a password to enable its access to the PaaSage platform and to the facilities provided; (b) cloud credentials exploited by the PaaSage platform to perform deployment tasks on behalf of the user in a certain cloud.

3. Solution Architecture

3.1. Introduction

The security solution envisaged for the PaaSage platform aims at securing all types of resources, i.e., information and service resources, offered with the primary goal to mainly work for single-site platform deployments. The design of this solution relied on the following principles and requirements:

• unique credentials are needed to access all types of resources. This greatly facilitates users as they just need to memorize only one credential set which is used across all platform entry points, components and modules.

• different permissions must be associated by default to different (basic) roles of an organisation. Administrators of these organisations can then update such permissions according to organisation needs and policies. This facilitates and accelerates the specification of permissions by considering that a basic set of same roles exists across different organisations and can be mapped approximately to the same set of permissions.

• an organisation should control the access type that other organisation users have, indicated from now on as external users, over information owned by this organisation. This requirement, when fulfilled, transforms MDDB into a multi-tenant store where each organisation has its own private space and controls external access to it.

• a super administrator is needed to deal with unforeseen security issues. Such a role must have full write access to the whole MDDB space.

• both internal and external identity providers can be used for user authentication. This translates to the capability of exploiting externally certified information to properly identify a user and map it to the roles assigned to it.

• the adoption of security standards, such as SAML2 and XACML3, must be enforced as it not only enables the conformance to such standards but also re-using existing software to realise part of, if not the whole, the required authentication and authorisation functionality

• exploit CDO's security technology to secure the access to CDO repositories in order not to lose time and redevelop the required security functionality from scratch

3.2. Architecture

The solution developed relies on realising certain security components which cooperatively interact with the CDO Repository. These components are used to authenticate users and authorize the access to information and service-based resources. The security components interact with the CDO so as to retrieve the required security information (users, roles and permissions) in the context of security tasks fulfillment. The secure access to information resources (i.e., models stored in MDDB) is realized through exploiting the CDO technology's security features.

Figure 3 depicts the overall solution architecture comprising eight main components. The CDOClient is exploited by many components to access information resources of the underlying CDO repository. This access, secured through using CDO technology, can involve normal information, needed by PaaSage components or UIs, or security-oriented organisation information required by the PaaSage security components responsible for user authentication and authorisation.

In the following, we analyze in more detail the main security components as well as highlight particular security specificities for components already analyzed in Section 2.

An Identity Provider (IDP) is a component responsible for user authentication. Two types of IDPs are envisaged: (a) external IDPs (like facebook) which authenticate users over their own user bases and return a token encompassing a valid identifier that can be exploited by our solution's security components to properly identify these users and retrieve the suitable security information related to them (such as their roles); (b) an internal IDP which authenticates users and returns a token containing all appropriate information that can be used to subsequently authorize them.

The Policy Enforcement and Policy Decision Points (PEP/PDP) are a couple of security components responsible for user authorisation which relay to SP the decision of whether users have appropriate rights to access the service



Fig. 3. The overall security solution architecture

resources requested. Such a decision relies on the permissions stored in CAMEL organisation models. This means that the PEP/PDP should discover those permissions pertaining to the requesting user (based on the roles assigned to this user) and examine whether they include the right to access the requested resource according to the access type (e.g., read/write/execute) involved.

In terms of this security solution, the SP was extended in order to: (a) retrieve user tokens, when produced in user authentication, and pass them along with the user requests to PEP/PDP; (b) redirect users to IDP for authentication in case of web access requests to platform resources.

The CDO Server has been regulated to work in a secure mode and allow access only to legitimate CDOClients, i.e., clients providing correct CDO credentials during session establishment. When credentials are correct, a CDOSession with the CDOServer is established to be used for performing any kind of action on the CDO Repository (store, update or query models), provided that the user mapping to these credentials has the respective rights to do so. The communication between the client and server can be secured via using SSL-based sessions in case any major security component, like IDP, is not situated inside the same VM with respect to the one hosting the CDO Repository.

To be correctly and appropriately integrated in the proposed security architecture, the UIs, IDEs and the SN must be enriched with the following capabilities: (a) enabling the selection of internal or external IDPs for users, which then maps to user redirection to the respective IDP's authentication page for credentials submission; (b) taking over authentication control by directly interacting with users and communicating in the background with IDP; (c) exploiting the CDOClient to authorize the access to information requested; (d) communicating with SP for service access requests by sending the user token and request to enable subsequent user authorisation via the PEP/PDP. Such capabilities map to a more-or-less lightweight integration between UI/IDE/SN and other security components as well as the CDOClient. In the rest of this section's analysis, for reasons of size economy, SN is solely mentioned but the involvement of the other two components is also assumed.

Figures 4(a-b) and 5(a-b) visualize the interactions between the architecture components involved in user authentication and authorization, respectively. In all figures, interactions have numberings reflecting their order with a prefix number indicating the type of security task involved (1 - authentication, 2 - authorisation). To reduce interaction complexity and cater for clarity and better comprehensiveness, only successful interactions are shown while some obvious steps, like subsequent service execution, are omitted. Figures 4(a-b) explicate the cases of web-based and programmatic authentication, respectively, while Figures 5(a-b) explicate authorisation of services and CDO models, respectively.

We now analyze the interactions in the context of these four security cases. Any authentication case can be combined with any authorisation one, leading to supporting four main security scenarios, providing an added-value to our solution: (a) web-based authentication & CDO authorisation; (b) web-based authentication & service authorisation; (c) programmatic authentication & CDO authorisation; (d) programmatic authentication & service authorisation.

During a web-based authentication, the SN communicates with the SP which redirects the user, after selecting a suitable IDP, to this IDP's authentication page. Then, the user provides his/her credentials which are checked against the IDP's user base. In case of unsuccessful authentication, the IDP returns an error message to the user.

(1.3) Get User information I1-4) User information retrieval

(1.5) User



(1.1) User credentials

(1.5) User token

(1.4) User information retrieval

(1.2) Get User (1-3) User information

information re trieval

ation I

Fig. 4. (a) Web-based authenication interactions

(b) Programmatic authentication interactions

(2.8) GrantAccess Decision

(2.1) User token + request

(2.7) Grant Access Decision

(2.4) Policy checking

Fig. 5. (a) CDO authorisation interactions

(b) Service authorisation interactions

For internal IDPs, checking is performed on the CDO repository by using a CDOClient. The CDOClient is initiated with user credentials and a session is attempted to be established with CDOServer. Upon successful session establishment (thus mapping to a successful authentication), a subsequent query is submitted to obtain the extra user information to be used for constructing the user token for authorisation. This token is then returned to the SN.

For external IDPs, the checking is performed against the own user base. Upon successful authentication, a user token is constructed, containing a particular user identifier, and returned to the SN.

The main difference between programmatic and web-based authentication is that for the former there is no redirection as SN must control the security workflow, thus passing from all suitable components of the solution architecture. This means that the SN must obtain user credentials and contact the internal IDP to validate them. The internal IDP is selected as it certainly supports programmatic authentication. Checking of user credentials then proceeds as in web-based authentication with the sole exception that the error message must be relied to the user by the SN.

CDO-based authorisation involves a simple interaction process. SN exploits the CDOClient to establish a session with CDOServer and issue the user request. As such, CDOClient is initiated via the user token, attempts to obtain user credentials from it and then uses these credentials to establish a session with the CDOServer. Upon successful session establishment, CDOClient issues the user request which is checked by the CDOServer according to the CDO permissions pertaining to the respective user. In case the user is allowed to have access to the related information resource, the user request is executed against the underlying store and the respective result is returned. Otherwise, an error message is sent back. Any type of result is relayed finally to the user.

Service-based authorisation starts with the SN sending the user token and request to the SP. SP redirects this information to the PEP which redirects it in turn to PDP. PDP then, either checks the authorisation information immediately or communicates with the CDOServer in case the user token does not contain all necessary user information (if an external authentication has taken place). In the latter case, the user token and respective user identifier is exploited to

obtain the roles assigned to this user from the CDO repository. In all cases, the authorisation checking is performed by examining the permissions in the CDO repository to discover those associated to the user roles. The latter permissions are then checked to see whether allow the user to perform the requested service action. Depending on the checking result, an access grant or denied decision is issued and propagated to PEP and then to SP. Depending on the authorisation outcome, SP will finally either allow the service call or send an error message to SN.

4. Information Integration

While the security solution seems quite clear and precise, it comes with certain issues that must be addressed. In particular, due to the need to have one CDO repository, exploit CAMEL organisation meta-model to express security-oriented information, and utilize the CDO security feature 4 which relies on information specified via a CDO security meta-model, we had to realize an information integration task mapping organisation models to CDO security ones.

To realize this task, we have followed a lightweight integration approach relying on the following two principles: (a) the meta-models remain independent and not truly integrated; (b) information integration is performed at the model level via transformations. Such an approach was followed for the following reasons: (a) CDO authentication and authorisation relies on the information specified by the CDO security meta-model and stored in a particular way, thus requiring modifying CDO code to update this way according to our needs; (c) using an organisation model and mapping into the CDO security one hides any complexities inherent in the CDO security meta-model and does not impose the requirement of having to learn many security DSLs to address different security cases.

In the following, we analyze the way information integration has been achieved for the CAMEL to CDO security mapping. In the end, we shortly analyze the administration API which reduces the risk of having invalid security specifications due to the non-propagation of updates of an organisation model to its mapped security one.

4.1. Organisation Meta-Model to CDO Security Meta-Model Mapping

As the CDO security meta-model includes concepts which have a more or less one-to-one mapping to the organisation meta-model, this greatly facilitates our integration task. The mapping between the CDO security and CAMEL organisation meta-models is visualized in Figure 6.

It can be easily seen that there are concepts with exactly an one-to-one association, like users and roles, while only the mapping of permissions is more involved. The latter relies on the fact that the CDO security meta-model is quite rich able to specify logical combinations of resource filters on permissions, while the organisation metamodel was designed with simplicity and basic security scenario coverage as its main design goals, thus allowing only simple resource filters to be specified for each permission mapping to concrete CDO resources or the content (folders/resources) of CDO resource folders. The mapping of a CAMEL organisation to a user group might be regarded as irrational but is required to establish a way to refer to all users of one organisation.

Before analyzing the mapping procedure, we need to explicate the types of actions allowed in permissions and a basic set of organisation roles. Three main action types can be used, depending also on the resource types to be involved. In particular, read and write action types must be used in information resource permissions, while the access action type can be used in service resource permissions. The basic set of organisation roles includes the following:

• admin: it can update the organisation model of its organisation. All other roles cannot even read this model.

• business: this role maps to a business-oriented user type. Such a role must be enabled to have a complete view on what is happening in its organisation in terms of the PaaSage platform (e.g., check current deployments cost) as well pose high-level security and cost requirements to drive the the organisation applications's deployment.

• devops: this is the most important organisation role. Its duty is to specify applications and all types of (CAMEL) models apart from organisational ones.

The mapping of roles to respective permissions is performed by default. However, an organisation can modify such default permissions based on its requirements as well as specify new roles. As such, we actually capture the


Fig. 6. Camel organisation to CDO security meta-model mapping

generic and common case in permission specification and leave exceptions to be handled by organisations themselves via suitable modification or extension of these permissions without having to write everything from scratch.

A special role, called external, must be specified to reflect what all other organisation users in a running PaaSage platform instance can see with respect to the information owned by a current organisation. The set of permissions attributed to this role can vary depending on each organisation needs. We foresee two main cases reflecting the set of permissions for such a role: (a) an organisation does not share anything with any other organisation - in this case there is no need to specify an external role for this organisation; (b) an organisation shares in read mode most of its models apart from critical ones (i.e., organisation model). Based on these two cases, we enable an organisation to choose one of two options for external access to its private information space, named as "totally.private" and "totally_visible", respectively, where the second option maps to creating an external role as well as assigning to this role a set of read access control permissions to most of the organisation's information resources.

Both the existence of such a role and the enablement of permission customisation for all basic roles creates the major issue that we cannot have basic roles or an external role which can be applied for every organisation but quite concrete roles pertaining to only one organisation. As such, the mapping between an organisation and a CDO security model should be adapted to cater for this restriction which leads to mapping basic/external roles in an organisation model to organisation specific roles in the CDO security model.

4.1.1. Mapping Procedure

Before executing the mapping procedure, we pre-process the organisation model to enrich it with permissions mapping to basic roles. Depending on the security level desired, an external role is also created for the organisation named as "external" and mapped to a set of permissions.

The transformation loads the organisation model in main memory and process it to perform a specific set of transformations for each type of object processed to enforce the more or less one-to-one mappings. As a secured CDO repository comprises only one CDO security model stored upon repository initialisation, each organisation model should be only mapped to this CDO model. The transformations involved in the mapping procedure are the following:

• an organisation is mapped to a CDO user group named after its name. As such, we connect all organisation users to one group enabling to create suitable user partitions and associate user groups to any permission that might hold for all users of these groups by directly associating the group to the role associated to such permission. In our case, a CDO user group is associated to all external roles for all organisations previously accounted for (had their models processed).

• each user is mapped to a CDO user with the same (PaaSage platform) credentials as those specified for him/her in the organisation model, where the user name maps to the CDO user ID and the password to the CDO UserPassword. Only a very small information from a CAMEL user to its equivalent CDO part (CDO User) is transformed to be focused and use the CDO security model only for information directly pertaining to user authentication. Each CDO user is associated to the user group of the current organisation (whose model is being processed).

• each role is mapped to a CDO Role, where the CDO Role's ID is constructed from the name of CAMEL role and respective organisation based on the following pattern: "<camel_role_name>_<organisation_name>". The external role is associated then to all user groups previously defined and stored apart from the current one.

• Each model-based permission (with read/write action type) is mapped to a permission in the CDO model as follows. First, a CDO Permission is created with the access attribute value mapping to the CAMEL permission's action type. Then, depending on the resource description, the respective CDO filter (permission core) is created. A resource description indicates the path to a resource or folder in the CDO Repository. As such, a ResourceFilter is created as the CDO permission core and the pattern style plus other boolean attributes are regulated to reflect whether we are dealing with a CDO resource or folder. In the end, one CDO permission is created, which is associated to a particular CDO role which is identified in turn via a query based on the naming scheme indicated in the previous bullet as well as the name of the CAMEL role.

• Each role assignment maps to an association from a user to the respective role assigned to it in the CDO model.

4.1.2. Illustrative Example

For better understanding the above mapping algorithm, a specific scenario is provided. Suppose one organisation A with 3 users Ui, U2 and U3 mapping to the three basic roles has been modelled in CAMEL. Further suppose another organisation B was also modelled with again three users V1, V2 and V3 mapping to the three roles. An external role is indirectly indicated for both organisations via selecting the "totally_visible" option. The CAMEL-to-CDO security model mapping algorithm will start processing A's organisation model by first creating one user group named as "A". Then, it will create the four required roles named as "admin_a", "devops_a", "business_a" and "externaLa". As no other organisation has been created before, the external role is not associated to any other user group. Then, we process the organisation's permissions and we create the respective CDO permissions. In the end, we create the organisation's users including them in the organisation's user group and mapping them to one of the three basic roles, while we also enforce the respective role assignments. Next, the processing of B's organisation model starts and leads to similar transformation results. However, there is a specific exception in this case: (a) B's created user group called "B" is associated to the external role of A ("externaLa") while A's user group is associated to B's external role named as "external_b". Thus, we can follow the processing of forthcoming organisation models in a similar fashion and associate all previous external roles to the new organisation model's user group as well as update past user groups with the association of the new organisation model's external role.

4.2. Administration API

The mapping approach followed comes with the risk of having organisation models and the CDO security model not correctly updated as updates on organisation models are not propagated to the CDO security one. As such, we have developed an administration API which, by relying on the fact that only organisation models are updated (either programmatically or via respective GUIs), guarantees that updates are propagated to the CDO model. Such an API allows also updating organisation model parts, such as information about users, roles and role assignments, while enables storing organisation models to the CDO repository. Thus, this API serves as a companion to administrators greatly assisting in supporting administrative tasks related to security information manipulation.

Implementing the administration API relied on developing and thus exploiting he CAMEL organisation to CDO security meta-model mapping algorithm. However, this algorithm logic identifies only the mappings between elements of these two meta-models. To support the addition but more importantly the updating and removal of security objects, the code also relied on the proper identification of respective CDO security objects via fixed naming schemes put in place in the mapping algorithm. We must, highlight, though, that the propagation of updates to the CDO model were not so easy as they could involve deleting and inserting various security objects in this model. It must be noted that, fortunately, not every possible update on the CAMEL organisation model must be propagated to the CDO security model. This greatly speeds up the performance of the update method and has led to simplifications in the API code development.

5. Related Work

We can distinguish between two types of multi-tenancy: (a) multi-tenancy at the platform level and (b) multi-tenancy at the application level. At the platform level, multi-tenancy maps to the ability to manage multiple customers and provide to them a private space which cannot be accessed by other customers. Such a private space can contain information related to the usage of the platform services by the customer but may also contain sensitive data about this customer. On the other hand, multi-tenancy at the application level maps to the capability to serve many clients within one instance of an application. Concerning the second multi-tenancy type, many sophisticated research proposals have been put in place6,7 while existing proprietary cloud frameworks support it, like the Namespace API in Google App Engine 5 or the SaaS Multi-Tenant Management Framework provided by TechCello 6. In this paper, we focus mainly on the first type of multi-tenancy along with respective issues concerned with securing the access to platform services and the following analysis is based on this.



Most proprietary platforms are able to support platform multi-tenancy due to need of handling business customers which pay for the services used and expect a certain privacy and security level. Major players like Amazon offering platforms such as AWS provide secure interfaces via which clients can access the respective services offered. However, this platform type does not consider at all information sharing as each organisation information is isolated and restricted to the use for that organisation. In addition, most of the time, no models can be used for users to describe deployment or performance requirements or organisation models and no mechanisms exist for model manipulation. In this respect, users should usually be developers or administrators having the ability to either use a certain user interface or REST API.

Most of the research proposals focus on providing a security layer on top of a cloud or multiple clouds. In8, a multi-tenant authorisation system with federated identity for cloud environments based on Shibboleth is proposed, which in contrast to other research approaches, is able to provide minimal user information to the SP as well as ensure mutual protection of both service providers and customers. An interesting but theoretical approach is proposed in9 where reverse access control is exploited in order for customers to control the way authentication and authorisation is performed by cloud providers while clouds providers guarantee that the customers do not violate the overall security policies of the cloud structure/hierarchy. A multi-tenant federated authorisation framework and architecture for cloud services is proposed in10 which adopts hierarchical role-based access control and path-based object hierarchies. The article in11 proposes four different types of multi-cloud architectures, categorizes the respective schemes employed and discusses their main benefits with respect to security aspects. Finally, the article in12 proposes a security solution for multi-clouds operating in multiple levels by providing three main services: (a) a VM security service, (b) a virtual network security service and (c) a policy-based trust management service. The latter service relies on particular techniques and mechanisms which enable access control over federated pool of resources as well as support trust federation via optimizing task privacy by also considering cost requirements.

In contrast to the currently proposed research and proprietary solutions and platforms, the PaaSage project offers a secure platform catering for different interaction types. It allows organisations to share their knowledge via the SN by also explicating the security level imposed on their private information spaces. It also allows exploiting the platform facilities in a web-based or programmatic way via the SN and the SP. It finally enables users to specify and manipulate models via which knowledge can be more easily derived and shared. The combination of all these features certainly provides an added-value to the PaaSage platform with respect to the competition, especially as it also promotes knowledge and expertise sharing in the cloud to promote the optimisation of application deployments in contrast to the private usage of state-of-the-art cloud platforms. PaaSage also enables the multi-cloud application deployment and provisioning, something not actually offered by current platform offerings which mainly cover single or hybrid cloud scenarios. We should also mention the consideration of all security aspects, which also leads to further optimizing cloud application deployments through filtering the cloud provider space based on security requirements as well as considering security metrics in optimisation formulas.

The PaaSage platform can of course benefit from the state-of-the-art. It is apparent that it has to evolve in order to secure not only the access to its data and services but also the user applications which are deployed and run on multi-cloud environments. It also needs to enable organisations to develop multi-tenant applications. To this end, it would be interesting to couple the existing platform services with additional features aiming at realizing the missing aspects through exploiting already proposed state-of-the-art techniques and services in data and VM isolation as well as multi-tenant application development. In addition, it would be interesting to inspect how well the theoretical approach in9 could be applied on the PaaSage security architecture such that it could allow a more flexible type of security enforcement based on the customer organisation requirements and the policies of the PaaSage platform operators. Finally, exploiting existing federated cloud-based security techniques could enable the PaaSage platform to support distributed developments linking different instances of the platform together. Such a federation of PaaSage instances could enhance the existing level of cloud knowledge and expertise sharing to further promote the added-value of multi-cloud platforms.

6. Conclusions

This paper presented a particular approach towards securing the access to services and information of a multi-

cloud platform. This approach relied on a particular architecture which can handle different security scenarios. This

approach also enables the transformation of a model-based repository into a multi-tenant store on which the access to organisation-specific information is restricted. To further facilitate the management of security-oriented information, a particular administration API is offered which enables the creation and updating of users, roles and permissions.

Through combining this approach with previous work on security focusing on managing security requirements and capabilities and considering such information in deployment planning to filter the cloud provider space, the PaaSage platform completes the support in all security aspects and is thus differentiated with respect to the main competition.

The following work directions are planned: (a) validating our approach according to particular use cases in PaaSage; (b) performing advanced testing to prove that our solution does not exhibit critical security issues; (d) supporting other security standards, like XACML; (e) coupling administration API with a UI vanishing the requirement of good knowledge of CAMEL organisation meta-model and EMF-based modelling expertise for administrators; (f) supporting secure federations of multiple PaaSage platform instances.


This work is partially funded by the EU FP7 PaaSage project.


1. Rossini, A., Nikolov, N.,Romero, D., Domaschka, J., Kritikos, K., Kirkham, T., etal. D2.1.2-CloudML Implementation Documentation (First version). PaaSage project deliverable;2014.

2. Kritikos, K., Massonet, P.. An Integrated Security Meta-Model for Run-Time and Design Time Cloud Deployment Adaptation. IEEE Transactions on Cloud Computing 2015;Under review.

3. Kritikos, K., Plexousakis, D.. Multi-Cloud Application Design through Cloud Service Composition. In: CLOUD. IEEE;2015,.

4. Jeffery, K., Houssos, N., Jörg, B., Asserson, A.. Research information management: the CERIF approach. IJMSO 2014;9(1):5-14. doi:10.1504/IJMSID.2014.059142.

5. Quinton, C., Romero, D.,Duchien, L.. Cardinality-based feature models with constraints: a pragmatic approach. In: Kishi, T., Jarzabek, S., Gnesi, S., editors. SPLC 2013: 17th International Software Product Line Conference. ACM. ISBN 978-1-4503-1968-3;2013, p. 162-166. doi:10.1145/2491627.2491638.

6. Cai, H., Wang, N., Zhou, M.J.. A Transparent Approach of Enabling SaaS Multi-tenancy in the Cloud. In: Services. IEEE;2010, p. 40-47.

7. Azeez, A.,Perera, S., Gamage, D., Linton, R., Siriwardana, P., Leelaratne, D., et al. Multi-Tenant SOA Middleware for Cloud Computing. In: Cloud. IEEE;2010, p. 458-465.

8. Leandro, M.A.P., Nascimento, T.J., dos Santos, D.R., Westphall, C.M., Westphall, C.B.. Multi-Tenancy Authorization System with Federated Identity for Cloud-Based Environments Using Shibboleth. In: ICN. IARIA;2012, p. 88-93.

9. Albeshri, A.A., Caelli, W.. Mutual Protection in a Cloud Computing Environment. In: HPCC. IEEE;2010, p. 641-646.

10. Calero, J.M.A., Edwards, N., Kirschnick, J., Wilcock, L., Wray, M.. Toward a Multi-Tenancy Authorization System for Cloud Services. IEEE Security and Privacy 2010;8(6):48-55.

11. Bohli, J.M., Gruschka, N., Jensen, M., Iacono, L.L., Marnau, N.. Security and Privacy-Enhancing Multicloud Architectures. IEEE Transactions on Dependable and Secure Computing 2013;10(4):212-224.

12. Li, J., Li, B., Wo, T., Hu, C., Huai, J., Liu, L., et al. Cyberguarder: A virtualization security assurance architecture for green cloud computing. Future Generation Computer Systems 2012;28(2):379 - 390. URL: pii/S0167739X1100063X. doi: