Standards for enabling heterogeneous IaaS cloud federations

11/21/2017 ∙ by Álvaro López García, et al. ∙ Universidad de Cantabria 0

Technology market is continuing a rapid growth phase where different resource providers and Cloud Management Frameworks are positioning to provide ad-hoc solutions -in terms of management interfaces, information discovery or billing- trying to differentiate from competitors but that as a result remain incompatible between them when addressing more complex scenarios like federated clouds. Grasping interoperability problems present in current infrastructures is then a must-do, tackled by studying how existing and emerging standards could enhance user experience in the cloud ecosystem. In this paper we will review the current open challenges in Infrastructure as a Service cloud interoperability and federation, as well as point to the potential standards that should alleviate these problems.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Cloud computing is still considered as an emerging technology, although it is now leaving its infancy phase. Standardization in the cloud was not considered as an urgent topic by the industry Dillon2010 , as it is often associated to rigidity, not leaving much room for the innovation needed on the early stages of the technology Tassey2000 .

Over the last years, a large number of commercial cloud providers have emerged in the market. Each of those vendors tries to differentiate their infrastructure from their competitors offering added value features on their resources. This has led to a situation where several closed and proprietary interfaces have evolved over the time, some being claimed as de-facto standards by the industry. The resulting scenario consists on infrastructures using different solutions that are actually incompatible and not interoperable, locking users inside a single provider. These vendor lock-ins are often considered a desirable feature by commercial providers, as a way of keeping users attached to their resources and services, but it is perceived negatively by cloud users and customers Borenstein2011 .

More recently, several open source Cloud Management Frameworks (CMFs) have appeared in the cloud ecosystem. Some of them decided to adopt the most popular commercial and proprietary interface, implement a compatibility layer that tries to deliver the same functionality; whereas others have built their own interface. Both decisions are contributing to adding more entropy and heterogeneity into the cloud ecosystem. Users willing to exploit several infrastructures face a discouraging panorama, with strong industrial actors driving the developments that have promoted a situation where proprietary and industry-driven interfaces and protocols have dominated the cloud landscape for years Petcu2013 .

As the cloud computing paradigm is maturing and its heterogeneity is growing, cloud interoperability and federation are becoming areas of concern Badger2011 ; James2015 . Federation and interoperability are nowadays considered as one of the main pressing issues towards cloud computing adoption Schubert2010 . The vendor lock-ins that currently exist are perceived negatively by users, therefore building and defining frameworks for cloud interoperability is becoming therefore a topic that is gaining more and more interest Campos2012 ; Bernstein2009 ; parak2014challenges ; Feldhaus2014 ; FernandezdelCastillo2015 . Moreover, political and government bodies such as the European Commission have stated their position towards the promotion of Open Standards for ensuring interoperability in clouds for science and public administration Idabc2004 ; Cattaneo2013 .

Nevertheless, cloud federation goes beyond just making several clouds interoperable Kurze2011 . A federation should enable the collaboration and cooperation of different providers in delivering resources to the users when a single resource provider is not able to satisfy the user demands, in a collaborative way. Therefore, on top of the interoperability and portability issues, there are several challenges that any federation must tackle.

In this paper we will review the open challenges when building an interoperable cloud federation. We will review the existing enabling standards that can be used to leverage the construction of such a federation of Infrastructure as a Service (IaaS) providers based on open standards. We will focus on an horizontal federation between different IaaS providers, therefore a vertical federation spanning several layers is out of the scope of this paper.

In Section 2 we will present the related work in the area. In Section 3 we will present the biggest challenges that an interoperable cloud federation must assess. In Section 4 we focus on the existing and raising standards and how they can be used to tackle the problems presented in Section 3. Finally we present our conclusions in Section 5.

2 Related work

Some work and research has been done into cloud interoperability, although a lot of the work is regarding cloud portability between different cloud infrastructures.

There are many non academic works regarding the need or lack thereof for a Cloud standard. However, authors agree that there would be not such a unique standard to rule all the cloud aspects. Some preliminary work regarding the need of standards for the cloud has been done in the past Borenstein2011 ; Machado2009 .

The United States’ National Institute of Standards and Technology has surveyed the existing standards for interoperability, performance, portability, security and accessibility in the NIST Cloud Computing Standards Roadmap Bumpus2013 . However, there are some aspects like information discovery or accounting that are missing in this study.

G. Lewis LewisTheRole2012 report tackles several standardization areas such as workload management, data and cloud management APIs, concluding that there will be not a single standard for the cloud due to pressures and the influences of existing vendors. The author states that an agreement on a set of standards for each of the needed areas would reduce the migration efforts and enable the third generation of cloud systems.

Harsh et al. Harsh2012 work surveyed the existing standards for the management of cloud computing services and infrastructure within the Contrail project so as to avoid vendor lock-in issues and ensure interoperability. In the same line, Zhang et al. Zhang2013 performed a quite complete survey regarding Infrastructure as a Service access, management and interoperability, studying OVF, CDMI and OCCI Zhang2013 . However, they have not entered into other details and challenges such as accounting or information discovery.

On top of those academic efforts, some open source Cloud Management Frameworks (CMFs) have started to take into consideration the federation issues. There are development efforts aimed to make possible to federate different aspects of distributed cloud infrastructures to an extent:

  • OpenStack web:openstack implements several levels of federation by the usage of cells and regions. The former allows to run a distributed cloud sharing the same API endpoint, whereas the latter is based on having separate API endpoints, federating some common services: OpenStack also allows the usage of a federated authentication mechanism Chadwick2014 , so that the identity service is able to authenticate users coming from trusted external services or from another identity service.

  • CloudStack web:cloudstack follows the same line and implements the concept of regions in their software.

  • OpenNebula web:opennebula makes possible to configure several installations into a tightly integrated federation, sharing the same users, groups and configurations along several installations.

  • Eucalyptus web:eucalyptus provides with identity and credential federation.

However, all of them rely on the fact of federating several instances of the same software stack (i.e. several OpenNebula installations, for instance), being impossible or difficult to federate disparate and heterogeneous infrastructures (e.g. an OpenStack installation together with an OpenNebula instance).

On top of that, there a few prominent existing federated infrastructures, some of them being built on top of standards, others not. Some examples of standards-based federations are the EUBrazil Cloud Connect web:eubrazil , whose middleware is being based on standards for interoperability DiasdeLima2014 ; and the European Grid Initiative (EGI) web:egi , that started as a federation of grid sites, took the strategic position of exploring and adopting a technology agnostic and based on open standards cloud FernandezdelCastillo2015 into their services portfolio. In this context, the Open Science Cloud initiative Koski2015 has outlined that interoperable, distributed and open principles should drive the evolution of Science Clouds as the key to success.

3 Cloud Federation Open Challenges

As we briefly exposed in Section 1, a cloud federation should take into account other aspects apart from interoperability and portability such as authentication, authorization or accounting. In the following sections we will elaborate on the open challenges regarding cloud federation.

3.1 On Uniform Access and Management

One of the first obstacles that a heterogeneous cloud federation has to overcome is the lack of a unified cloud interface. Evolving from commercial cloud providers, each middleware implements their own —proprietary or not— interface. Some open CMFs implement an Amazon Web Services (AWS) EC2 web:aws compatibility layer, since it was considered as the most popular commercial interface for the cloud.

The adoption of the AWS EC2 API could make two different CMFs being interoperable, but it presents several obvious drawbacks. First of all, its usage and promotion introduces a vendor lock-in, as users can be locked into one infrastructure if the original vendor decides to change its API from one day to another. A proprietary API is subject to change without prior advice by the original vendor. This will render into incompatibilities between providers and CMFs other than the original creator of the API, Amazon in this case. Implementers of such proprietary interfaces need to keep aligned with the reference implementation, and are forced to invest time in following the modifications so that they ensure that its implementation remains compatible.

Secondly, the EC2 Query API is not RESTful. Even if it uses the standard components of the HTTP protocol to represent API actions it does not use the HTTP message components to indicate the API operations, being them expressed as parameters (in the URI parameters of a GET request or in the body of a POST request). This URI-based parameter passing is not enough for defining an interoperable API allowing an standardized implementation. Moreover, non being RESTful introduces additional complexity for developers to create applications that exploit it, as they have to learn the semantics being used instead of the well known REST architectural style. Lastly, the usage of the query component of an URI to obtain hierarchical data goes against the RFC-3986 ”Uniform Resource Identifier (URI): Generic Syntax” Berners-Lee2014 , as it states that ”The query component contains non-hierarchical data that along with data in the path component, serves to identify a resource (…)”.

3.2 On Portability

Cloud computing leverages virtualization technologies to abstract the resources being offered to the users. Several virtualization hypervisors (such as Xen, KVM, VMWare, Hyper-V) exist in the market, and each cloud provider will be using the one of its choice. Moreover, recently operating system level virtualization (that is, container-based such as LXC, OpenVZ and Docker) have entered the game and they are being more and more adopted by the providers.

This situation renders difficult the migration of one virtual appliance prepared to be executed in one cloud provider using one virtualization technology to another provider with a different underlying technology. Moreover, the underlying technology is hidden and abstracted from the users by the CMFs, hence even if they had the technological skills to prepare and modify a virtual appliance to be executed on another hypervisor they would have found difficulties in doing so. Porting one Virtual Machine to another hypervisor may require access to consoles and debugging output that cloud providers may be reluctant to provide.

3.3 On authentication and authorization

The delivery of an homogeneous authentication and authorization via a federated identity management system in distributed environment is a challenging topic Chadwick2014 ; Shim2001 not exclusive to cloud computing. As a matter of fact, cloud computing is just another player in the game. Such system should facilitate flexible authentication methods and federated authorization management.

The lack of a federated identity management systems makes difficult to manage the users globally at the federation, that is, specifying what resources a user is able to access or globally disabling a user becomes a challenging task.

Moreover, this challenge has two additional faces as it affects both the users and the resource providers.

  • From the user’s perspective, they are forced to cope with the burden of managing several credentials and identities. Moreover, client tools need to deal with them as well, identifying that identity A should be used against provider A but not provider B.

  • It increases the management complexity for the resource providers. If there is not such a federated identity management system, users are to be managed manually, thus incurring in a tremendous overhead.

3.4 On information discovery

Once a federation is established, the next challenge is how users are able to discover what resources and capabilities are offered by the federation so that they can consume them.

This information may be exposed to the users via each of the middleware native APIs by each of the resource providers participating in the federation, but it is not structured in an homogeneous way so that clients can fetch that information and help users making a decision.

3.5 On accounting and billing

In federated infrastructures it is often required to keep track of resource usage for each user and group at every individual provider, so that this information is shared and aggregated at the federation level and users are accounted properly. This aspect is tightly coupled with the federated identity management systems, as users need to be unambiguously identified throughout the infrastructure. Currently, each Cloud Management Framework and provider may have their own account method, but there is no common way for accessing and/or aggregating that information at the federation level.

4 Federation enabling standards

It may be possible to obtain interoperability without the usage of Open Standards web:open_standards , but it is arguably a more logical way to develop an interoperable federation based on them.

There is not a unique cloud standard to rule all of the aspects regarding clouds Machado2009 , neither there is such a federation standard. Nevertheless, there are several well established standards covering some of the open issues described in Section 3, developed prior to the raise of Cloud computing and that can be simply reused, adapted or updated to fill in the needed gaps. On top of them there is a number of emerging standards being developed specifically to cover more specific cloud computing topics.

It is the combination of both —existing and emerging standards— they key to solve the federation and interoperability issues described in Section 3, as we will describe through the rest of the section.

4.1 Uniform access and management

Several organizations and standardization bodies have started working from the early stages of cloud computing trying to build standards for cloud management. Currently, the most prominent examples regarding IaaS computing and storage management are OCCI, CIMI, TOSCA and CDMI:

OCCI

The Open Grid Forum (OGF) web:ogf has proposed the Open Cloud Computing Interface (OCCI) Metsch2011 ; Nyren2010 ; Metsch2010 , focusing on facilitating an interoperable access and management of IaaS cloud resources. OCCI offers different renderings over the HTTP protocol, leading to a RESTful API implementation.

CIMI

The Cloud Infrastructure Management Interface (CIMI) davis2012cloud is a proposal from the Distributed Management Task Force (DMTF) web:dmtf that has been recently registered as an ISO/IEC standard CIMIIso . CIMI targets the management of the life-cycle of the IaaS resources, offering a RESTful API over the HTTP protocol with various renderings.

TOSCA

The Topology and Orchestration Specification for Cloud Applications (TOSCA) Lipton2013 is an standard from the Organization for the Advancement of Structured Information Standards (OASIS) web:oasis . TOSCA provides a language to describe composite services and applications on a cloud, as well as their relationships (i.e. the topology), makes also possible to describe its operational and management aspects (i.e. its orchestration). Although TOSCA is at a higher level than simply managing the IaaS resources —it is more focused on the orchestration of the resources—, it should be considered as a complementary standard for the management of the resources.

CDMI

The Storage Networking Industry Association (SNIA) has proposed the Cloud Data Management Interface (CDMI), defining an interface to perform different operations (creation, retrieval, update and removal) on data stored on a cloud.

4.2 Portability

The Open Virtualization Format (OVF) crosby2009open is a standard developed by the DMTF for packaging and describing a Virtual Appliance (VA), comprised of an arbitrary number of virtual machines in a portable and vendor neutral format. An OVF package contains a XML description (e.g. hardware configuration, disks used, network configuration, contextualization information, etc.) of each component of the VA.

4.3 Authentication and authorization

There is a large number of standards that can be used for authentication and authorization. The implementation and adoption of one technology or another will eventually depend on the infrastructures that are going to be federated, and there will be no silver bullet that will fit all of the existing infrastructures. Authentication and Authorization sometimes imply political aspects that are out of the scope of the standardization efforts.

The X.509 Public Key Infrastructure rfc2459 has been used for authentication in the grid world via the Grid Security Infrastructure (GSI), based on X.509 certificate proxies rfc3820 . Authorization is done by embedding Attribute Certificates (AC) into the proxy, containing assertions about the user. The most notable service is the Virtual Organization Management System (VOMS) Venturi2007 , being used in some federated cloud infrastructures LopezGarcia2013 . However, X.509 certificates are not considered being user-friendly in spite of being settled on several distributed infrastructures over the years.

The OASIS Security Assertion Markup Language (SAML) oasis2005protocols is built in X.509 and defines a way to define authentication and attribute assertions in XML. Shibboleth shibboleth is an implementation of SAML and is focused on the federation of resource providers with different authentication and authorization schemes. Several projects have started looking at SAML and Shibboleth qiang2012standards ; murri2011gridcertlib as a promising way to provide access to distributed infrastructures, although they have not substituted X.509 yet.

OAuth 1.0 hardt2012oauth and 2.0 oauth is an IETF open standard for authorization, providing delegated access to some resources on behalf of the resource owner. OAuth has not been designed for authentication, therefore OpenID Connect (OIDC) sakimura2014openid has been developed as an authentication layer on top of OAuth 2.0.

4.4 Information discovery

Information discovery is a problem present in other federated computing paradigms such as Grids. The Grid Laboratory Uniform Environment (GLUE) Schema —in its versions 1.x Andreozzi2007 and 2.0 Andreozzi2009 — has been designed by the OGF in order to create an information model relying on the knowledge and experience from the operations of several large Grid infrastructures.

The current GLUE 2.0 specification Andreozzi2009 only defines a conceptual model. It makes possible to publish, separately from the standard, concrete data model profiles that will dictate how the information is generated and used for in concrete implementation, infrastructure, etc. Therefore, the OGF GLUE 2.0 schema is a good candidate for publishing information relative to cloud infrastructures.

4.5 Accounting

As with the information discovery, the accounting problem is a problem that has been already tackled in the grid. The OGF Usage Record (UR) 2.0 Cristofori2013 defines a common format to share and exchange basic accounting data, coming from different providers and different resources. It supersedes and integrates the different resource usage records that leveraged the previous UR 1.0 in the various infrastructures that implemented it.

The OGF UR does not specify how the records should be exploited (e.g. how they should be exported, used, aggregated, summarized, etc.) or transported. Examples on how the UR is used exist in projects such as RESERVOIR Elmroth2009 and infrastructures such as EGI web:egi .

5 Conclusions

As we explained, cloud federation involves a lot of different areas and challenges —management, authentication, accounting, interoperability, etc—, therefore there is not a unique standard for it. However, there is a set of settled and emerging standards that can cover all the federation aspects and their problematics, as summarized in Table 1.

Challenge Enabling Standard
Uniform access and management OGF OCCI Metsch2011 ; Nyren2010 ; Metsch2010
DMTF CIMI davis2012cloud
OASIS TOSCA Lipton2013
Portability DMTF OVF crosby2009open
Authentication and authorization OASIS SAML oasis2005protocols
OpenID Connect sakimura2014openid
X.509 rfc2459
Information discovery OGF GLUE Andreozzi2007 ; Andreozzi2009
Accounting OGF UR Cristofori2013
Table 1: Summary of enabling standards

In this document we have presented the existing challenges that need to be tackled for building an interoperable federation of cloud providers and we have surveyed the existing and arising standards that can be used to solve those problems. Current Cloud Management Frameworks should adopt these existing standards for the functionality they are offering, so as to avoid vendor lock-in issues and to ensure a that proper interoperability is delivered to the users.

The European Commission is encouraging the usage of Open Standards in its ”European Interoperability Framework for pan-European eGovernment Services“ Idabc2004 . Similarly, the United Kingdom Government provided a similar set of principles, adopted 2014 web:open_standards:uk . Other European initiatives, such as the Open Science Cloud Koski2015 , are also promoting the usage of Open Standards. Cloud federations must take into account these recommendations and they should promote its usage as the path to a successful federation and interoperability.

Acknowledgements

The authors acknowledge the financial support from the European Commission (via EGI-InSPIRE Grant Contract number RI-261323).

The authors also want to thank the IFCA Advanced Computing and e-Science Group.

References

  • (1) T. Dillon, C. W. C. Wu, E. Chang, Cloud Computing: Issues and Challenges, in: Advanced Information Networking and Applications (AINA), 2010 24th IEEE International Conference on, 2010, pp. 27–33. doi:10.1109/AINA.2010.187.
  • (2) G. Tassey, Standardization in technology-based markets, Research Policy 29 (4) (2000) 587–602.
  • (3) N. Borenstein, J. Blake, Cloud computing standards: Where’s the beef?, IEEE Internet Computing 15 (3) (2011) 74–78. doi:10.1109/MIC.2011.58.
  • (4) D. Petcu, G. Macariu, S. Panica, C. Cračiun, Portable cloud applications - From theory to practice, Future Generation Computer Systems 29 (6) (2013) 1417–1430. doi:10.1016/j.future.2012.01.009.
    URL http://dx.doi.org/10.1016/j.future.2012.01.009
  • (5) L. Badger, T. Grance, R. Patt Corner, J. Voas, Cloud Computing Synopsis and Recommendations, Tech. rep. (2011). doi:2012.
    URL http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-SP800-146.pdf
  • (6) A. James, J.-Y. Chung, Business and Industry Specific Cloud: Challenges and opportunities, Future Generation Computer Systems 48 (2015) 39–45. doi:10.1016/j.future.2014.12.006.
    URL http://www.sciencedirect.com/science/article/pii/S0167739X14002593
  • (7) L. Schubert, K. Jeffery, B. Neidecker-Lutz, The Future of Cloud Computing. Opportunities for European Cloud Computing Beyond 2010, Tech. rep., European Commission (2010). doi:10.1016/B978-1-59749-537-0.00012-0.
  • (8) E. Fernández-del Castillo, A. López García, I. Campos Plasencia, M. A. Nuñez Vega, J. Marco de Lucas, J. Gomes, G. Borges, M. David, I. Blanquer, M. Caballer, C. Alfonso, IberCloud: federated access to virtualized resources, in: Proceedings of the IBERGRID 2012 Conference, Lisbon, 2012.
  • (9) D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, M. Morrow, Blueprint for the intercloud - Protocols and formats for cloud computing interoperability, Proceedings of the 2009 4th International Conference on Internet and Web Applications and Services, ICIW 2009 (2009) 328–336doi:10.1109/ICIW.2009.55.
  • (10) B. Parák, Z. Ustr, B. Par, Challenges in Achieving IaaS Cloud Interoperability across Multiple Cloud Management Frameworks, in: Utility and Cloud Computing (UCC), 2014 IEEE/ACM 7th International Conference on, IEEE, 2014, pp. 404–411.
  • (11) B. Parak, Z. Sustr, F. Feldhaus, P. Kasprzak, M. Srba, The rOCCI Project – Providing Cloud Interoperability with OCCI 1.1 (2014) 1–15.
  • (12) E. Fernández-del Castillo, D. Scardaci, A. Lopez Garcia, The EGI Federated Cloud e-Infrastructure, in: Procedia Computer Science, 2015.
  • (13) Idabc, European Interoperability Framework for pan-European eGovernment Services, European Commission version 1 (2004) 1–25. doi:10.1109/HICSS.2007.68.
  • (14) G. Cattaneo, M. Claps, S. Conway, M. I. Bardellini, S. Muscella, S. Parker, N. T. I. Ferguson, Cloud for science and public authorities, Tech. rep., European Commission (2013). doi:10.2759/25446.
  • (15) T. Kurze, M. Klems, D. Bermbach, A. Lenk, S. Tai, M. Kunze, Cloud Federation, in: Proceedings of the 2nd International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING 2011), 2011.
  • (16) G. S. Machado, D. Hausheer, B. Stiller, Considerations on the Interoperability of and between Cloud Computing Standards, Scenario (Section 4) (2009) 1–4.
  • (17) W. Bumpus, NIST Cloud Computing Standards Roadmap, Tech. rep. (2013). doi:10.6028/NIST.SP.500-291r2.
  • (18) G. a. Lewis, The Role of Standards in Cloud- Computing Interoperability, Tech. Rep. CMU/SEI-2012-TN-012, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (2012).
  • (19) P. Harsh, F. Dudouet, R. G. Cascella, Y. Jegou, C. Morin, Using open standards for interoperability issues, solutions, and challenges facing cloud computing, in: Network and service management (cnsm), 2012 8th international conference and 2012 workshop on systems virtualiztion management (svm), 2012, pp. 435–440. arXiv:arXiv:1207.5949v1.
  • (20) Z. Zhang, C. Wu, D. W. L. Cheung, A Survey on Cloud Interoperability: Taxonomies, Standards, and Practice, SIGMETRICS Perform. Eval. Rev. 40 (4) (2013) 13–22. doi:10.1145/2479942.2479945.
  • (21) OpenStack Foundation, OpenStack (2015).
    URL http://openstack.org
  • (22) D. W. Chadwick, K. Siu, C. Lee, Y. Fouillat, D. Germonville, Adding Federated Identity Management to OpenStack, Journal of Grid Computing 12 (1) (2014) 3–27. doi:10.1007/s10723-013-9283-2.
  • (23) Apache Foundation, CloudStack (2015).
    URL http://cloudstack.apache.org/
  • (24) OpenNebula Project, OpenNebula (2015).
    URL http://opennebula.org/
  • (25) Eucalyptus Systems, Eucalyptus (2015).
    URL https://www.eucalyptus.com/
  • (26) EUBrazil Cloud Connect, EUBrazil Cloud Connect (2015).
    URL http://www.eubrazilcloudconnect.eu/
  • (27) M. J. Dias de Lima, G. Baptista, D3.1 Adaptation Requirements for CSGrid Middleware, Tech. rep., EU-Brazil Cloud Connect (2014).
  • (28) European Grid Initiative, EGI (2015).
    URL http://egi.eu
  • (29) K. Koski, K. Hormia-Poutanen, M. Chatzopoulos, Y. Legré, B. Day, Position Paper: European Open Science Cloud for Research, Tech. Rep. October, EUDAT, LIBER, OpenAIRE, EGI, GÉANT, Bari (2015).
  • (30) Amazon, Amazon Web Services (2015).
    URL http://aws.amazon.com
  • (31) T. Berners-Lee, R. Fielding, L. Masinter, Rfc 3986 - Uniform Resource Identifier (URI): Generic syntax.
  • (32) S. S. Y. Shim, G. Bhalla, V. Pendyala, Federated Identity Management, Computer 38 (September) (2001) 120–122. doi:10.1109/MC.2005.408.
  • (33) International Telecommunication Union (ITU), Definition of “open standards (2015).
    URL http://www.itu.int/en/ITU-T/ipr/Pages/open.aspx
  • (34) Open Grid Forum (OGF) (2015).
    URL https://www.ogf.org
  • (35) T. Metsch, A. Edmonds, Open cloud computing interface-RESTful HTTP rendering, Tech. rep., Open Grid Forum (2011).
  • (36) R. Nyrén, T. Metsch, A. Edmonds, A. Papaspyrou, Open cloud computing interface–core, Tech. rep., Open Grid Forum (2010).
  • (37) T. Metsch, A. Edmonds, Open cloud computing interface-infrastructure, Tech. rep., Open Grid Forum (2010).
  • (38) DMTF Cloud Management Working Group, Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol, Tech. rep., DMTF Cloud Management Working Group (2012).
  • (39) Distributed Management Task Force (DMTF) (2015).
    URL https://www.dmtf.org
  • (40) DMTF Cloud Management Working Group, Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol – An Interface for Managing Cloud Infrastructure, ISO ISO/IEC 19831:2015, ISO (2015).
  • (41) P. C. T. Lipton, S. I. Moser, D. V. Palma, T. I. Spatzier, Topology and Orchestration Specification for Cloud Applications, Tech. rep., OASIS Standard (2013).
  • (42) Organization for the Advancement of Structured Information Standards (OASIS) (2015).
    URL https://www.oasis-open.org
  • (43) DMTF OVF Workgroup, Open Virtualization Format Specification (OVF), Tech. rep., DMTF Standard (2014).
  • (44) R. Housley, W. F. T. Polk, D. Solo, Internet x.509 public key infrastructure certificate and crl profile, Internet RFC 2549.
  • (45) S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson, Internet x.509 public key infrastructure (pki) proxy certificate profile, Internet RFC 3820 (June 2004).
  • (46) V. Venturi, F. Stagni, Virtual organization management across middleware boundaries, in: IEEE International Conference on e-Science and Grid Computing, 2007, pp. 545–552. doi:10.1109/e-Science.2007.19.
  • (47) A. López García, E. Fernández-del Castillo, M. Puel, Identity Federation with VOMS in Cloud Infrastructures, in: 2013 IEEE International Conference on Cloud Computing Technology and Science (IEEE Cloudcom 2013), 2013, pp. 42–48. doi:10.1109/CloudCom.2013.13.
  • (48) OASIS, Assertions and Protocols for the OASIS security assertion markup language (SAML) v2.0, OASIS Standard 15.
  • (49) R. L. B. Morgan, S. Cantor, S. Carmody, W. Hoehn, K. Klingenstein, Federated Security: The Shibboleth Approach, EDUCAUSE quarterly 27 (4) (2004) 12–17.
  • (50) W. Qiang, A. Konstantinov, D. Zou, L. T. Yang, A standards-based interoperable single sign-on framework in ARC Grid middleware, Journal of Network and Computer Applications 35 (3) (2012) 892–904.
  • (51) R. Murri, P. Z. Kunszt, S. Maffioletti, V. Tschopp, GridCertLib: a single sign-on solution for Grid web applications and portals, Journal of Grid Computing 9 (4) (2011) 441–453.
  • (52) D. Hardt, The OAuth 2.0 authorization framework, Tech. rep., Internet Engineering Task Force (2012).
  • (53) B. Leiba, OAuth web authorization protocol, IEEE Internet Computing 16 (1) (2012) 74–77. doi:10.1109/MIC.2012.11.
  • (54) N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore, Openid connect core 1.0, The OpenID Foundation.
  • (55) S. Andreozzi, B. Stephen, L. Field, S. Fisher, J. Jensen, K. Balazs, M. Viljoen, A. Wilson, R. Zappi, GLUE Schema Specification version 1.3, Open Grid Forum-Glue Schema Working group (2007) 1–26.
  • (56) S. Andreozzi, S. Burke, L. Field, G. Galang, B. Konya, M. Litmaath, P. Millar, J. Navarro, GLUE Specification v. 2.0, Open Grid Forum-Glue Schema Working group (2009) 76.
  • (57) A. Cristofori, J. K. Nilsen, J. Gordon, M. Jones, J. A. Kennedy, R. Müller-Pfefferkorn, Usage Record – Format Recommendation, Open Grid Forum (2013) 1–62.
  • (58) E. Elmroth, F. G. Márquez, D. Henriksson, D. P. Ferrera, Accounting and billing for federated cloud infrastructures, 8th International Conference on Grid and Cooperative Computing, GCC 2009 (2009) 268–275doi:10.1109/GCC.2009.37.
  • (59) UK Government Cabinet Office, Open Standards Principles (2015).
    URL https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles