You are on page 1of 59

MSc Dissertation

Providing Moonshot access to OpenStack


Vincent Giersch - <vg66@kent.ac.uk>
MSc Computer Security - University of Kent 2012/2013 Supervisor: David Chadwick

Page 1 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Abstract
Today, Cloud Computing is widespread in many companies across the world. As a Cloud Infrastructure grows its provisioning and user management become complicated. The OpenStack project responds to this need of simplification of the computing resources management by providing a management layer of the computing resources, transforming any cloud infrastructure as an Infrastructure as a Service (IaaS). These cloud infrastructures are usually shared between different organisations, and the credential management becomes a new problem when different users utilise the same OpenStack infrastructure across a federation of organisations. The Federated Keystone project aims to provide a federated authentication and authorisation functionality to OpenStack by implementing different existing authentication solutions: their usage adds flexibility to the OpenStack users and resources provisioning. Moonshot is a JANET 1 project that brings federated authentication to nonweb applications using the IETF ABFAB protocol suite that is currently under development. Unlike the majority of other federated authentication solutions, ABFAB is not browser based. This project provides a tremendous opportunity to allow the federated usage of OpenStack without the need to embed a web browser inside the OpenStack clients. This document outlines the conception, implementation and testing of the Moonshot integration in OpenStack as a federated authentication solution.

Janet is a private UK government-funded organisation, which provides computing solutions and services for the education and research. [67] Page 2 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Acknowledgments
I would like to thank David Chadwick and Kristy Siu for their help and support during this masters project.

Page 3 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Table of contents
Abstract ...................................................................................................................... 2! Acknowledgments .................................................................................................... 3! Table of contents ...................................................................................................... 4! Table of illustrations ................................................................................................. 6! 1.! Introduction ......................................................................................................... 7! 1.1! Context ........................................................................................................... 7! 1.2! Objectives of this project ................................................................................ 9! 1.3! Overview of this dissertation......................................................................... 10! 2.! Literature survey ............................................................................................... 11! 2.1! Cloud computing .......................................................................................... 11! 2.2! OpenStack .................................................................................................... 12! 2.2.1! Introduction to OpenStack ..................................................................... 12! 2.2.2! The subprojects of OpenStack .............................................................. 12! 2.2.3! OpenStack Keystone ............................................................................. 13! 2.3! Federated identity management ................................................................... 13! 2.4! Shibboleth ..................................................................................................... 14! 2.5! Moonshot ...................................................................................................... 15! 2.5.1! Introduction to Moonshot ....................................................................... 15! 2.5.2! The Moonshot design and technologies ................................................ 16! 3.! Federated Keystone ......................................................................................... 19! 3.1! OpenStack Keystone .................................................................................... 19! 3.2! The Federated Keystone Blueprint ............................................................... 24! 3.2.1! First version API v2 .............................................................................. 24! 3.2.2! Second version API v3 ........................................................................ 27! 4.! Project design ................................................................................................... 30! 4.1! The GSS-API Moonshot Python Bindings Module ....................................... 31! 4.2! The HTTP API Design ................................................................................... 33! 4.2.1! First version API v2 .............................................................................. 33! 4.2.2! Second version API v3 ........................................................................ 37! 4.3! Python module design .................................................................................. 42! 4.3.1! First version ............................................................................................ 42! 4.3.2! Second version....................................................................................... 42! 5.! Project implementation .................................................................................... 43! 5.1! A Python module for Moonshot .................................................................... 43! 5.2! The Federated Keystone protocol: Moonshot .............................................. 43! 5.2.1! First version ............................................................................................ 43! 5.2.2! Second version....................................................................................... 44! 6.! Testing and validation ...................................................................................... 45! 6.1! Functional testing.......................................................................................... 45! 6.2! Acceptance testing ....................................................................................... 45! Page 4 of 59

Providing Moonshot access to OpenStack 6.2.1! 6.2.2! 6.2.3! 6.2.4! 6.2.5! 6.2.6! 6.2.7!

Vincent Giersch vg66@kent.ac.uk

An OpenStack testing client ................................................................... 45! Planning of the infrastructure setup ....................................................... 46! A Freeradius rlm_python module ........................................................... 47! First step of the setup: a single domain, sec.cs.kent.ac.uk ................ 48! Second step of the setup: multiple domains ......................................... 49! Acceptance tests.................................................................................... 50! Summary of these tests ......................................................................... 51!

7.! Conclusion ........................................................................................................ 53! 7.1! Current limitations ......................................................................................... 53! 7.2! Further research ............................................................................................ 54! 8.! References ........................................................................................................ 55! 9.! Appendix 1: Architecture of OpenStack Grizzly ............................................ 59!

Page 5 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Table of illustrations
Figure 1: The three usual Cloud Computing layers Source: OVH.com .................. 11! Figure 2: Separate resource allocations Source: OpenStack Foundation ............. 12! Figure 3: Federated authentication flow using Shibboleth ....................................... 15! Figure 4: Moonshot protocol flow ............................................................................. 17! Figure 5: The Moonshot user interface designed to manage multiple identities ...... 18! Figure 6: Keystone v3 authentication flow ................................................................ 19! Figure 7: Federated Keystone designed as a Keystone middleware ........................ 24! Figure 8: Federated Keystone v2 designed as a Keystone middleware ................... 26! Figure 9: The Keystone federated authentication plugin .......................................... 27! Figure 10: Keystone application stack design .......................................................... 30! Figure 11: The final step of the setup of the acceptance testing .............................. 46! Figure 12: The first step of the setup of the acceptance testing .............................. 48! Figure 13: Authentication flow for a user of sec.cs.kent.ac.uk .............................. 48! Figure 14: Authentication flow of a user of kent.ac.uk........................................... 50! Figure 15: Conceptual schema of the OpenStack Grizzly architecture - Source Solinea.com ....................................................................................................... 59!

Page 6 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

1. Introduction
1.1 Context
Today, computing solutions use more and more cloud computing from the development phase to production, for compute power (CPU, RAM), storage and networking: the main idea is to have every resource as a service, with a feeling of unlimited storage, bandwidth and computing power. This evolution is made possible by the virtualisation of the physical servers and networks: the compute power is provided as a service (IaaS, Infrastructure as a Service). This virtualisation of the computing infrastructure is handled by virtualisation software solutions called hypervisors (e.g. VMWare ESX, Citrix XEN Server, KVM, etc.). The management of these hypervisors and the virtualised resources is usually possible using a single and non-standard software solution. This limits and complicates the potential evolutions of the infrastructure, as well as the management and the provisioning of the resources, especially when an infrastructure uses different hypervisors. To solve this problem, we chose to focus on OpenStack, an open source cloud computing system that is designed to be easily managed, to control large pools of compute, storage and networking resources, and to allocate them to many users. OpenStack is a famous project supported by more than 150 companies across the world [1], including the hardware manufacturers and virtualisation software vendors themselves (e.g. HP, Cisco, Intel, Juniper, VMWare, etc.). But our idea goes beyond the simple use of OpenStack: we can easily manage our resources in a unified way using the APIs and interfaces provided by OpenStack. Instead we want to use existing users accounts in identity providers, to auto provision user entries in OpenStack through pre-established trust arrangements. This is more flexible and makes it easier to maintain very large numbers of users on an Internet scale. To realise this feature, this dissertation focuses on Keystone, the OpenStack identity management service [2], and more specifically on the Blueprint Federated Keystone written and developed by the University of Kent [3]. The Blueprints goal is to build a common API in Keystone that is capable of using a multitude of alternative external Identity Providers. When the current MSc project started, Kents federated Keystone already supported the SAML federation protocol [4] and Keystones proprietary protocol. As an alternative federated authentication solution, we chose to use the ABFAB protocol suite that is currently under development in the IETF [5], and the JANET Moonshot software, currently under research and development, which is the first public open source implementation of ABFAB. The Moonshot software was just at the beginning of its piloting and testing phase when this MSc project started. Page 7 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Moonshot provides a non-web authentication solution and is built on already deployed and proven technologies such as Radius [6] and EAP [7]. The main goal of Moonshot is to federate anything and everything easily without the need to embed a web browser inside the software clients (unlike for example OpenID [8] and SAML which generally assume the user is using a web browser).

Page 8 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

1.2 Objectives of this project


The objective of this masters project is to provide a non-web based federated authentication and authorisation mechanism for OpenStack services using external trusted identity providers to authenticate and authorise the users, by adding support for the IETFs ABFAB protocol suite (as implemented in the JANET Moonshot software). Once implemented, a user of a Moonshoted OpenStack service possessing a Moonshot identity will be able to login into the federated Keystone and to retrieve an OpenStack token providing him/her with access to his/her allocated cloud resources. Of course, this user would have to use an OpenStack client with the Moonshot libraries installed that implement the Federated Keystone authentication mechanism with the Moonshot protocol, for example, by using the command-line Swift client implementing the Federation Keystone API and the Moonshot protocol. Since the Moonshot project is at the beginning of the piloting phase there is no existing ABFAB federated infrastructure. Consequently the tested user identities will be limited to dummy users of the testing IdP servers. The requirements can be summarised as: 1. Provide federated access to OpenStack without requiring the use of a web browser. 2. Provide federated access to OpenStack using the ABFAB protocol suite [5] (as implemented by the Moonshot project). 3. Demonstrate that different users from one domain can access OpenStack services located in another domain with different access rights. 4. Demonstrate that different users in the same domain as an OpenStack service can access the OpenStack services with different access rights, using the same infrastructure and user interface as in 3. above. 5. Allow the administrator of the OpenStack service to configure different access rights to different federated users from different domains.

Page 9 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

1.3 Overview of this dissertation


This dissertation is written in several parts: the next chapter contains a literature review about Cloud computing, OpenStack, the concept of federated authentication and authorisation, and the IETF ABFAB protocol suite. Chapter 3 describes the OpenStack Keystone identity service in detail, Kents original Federated Keystone design, and its necessary evolution to support the ABFAB protocol suite. Chapter 4 explains the design of this project, the integration of the ABFAB protocol suite, the different software modules and the REST API. Chapter 5 describes the implementation of the project in its two different versions, using the Moonshot software, as well as the different problems that were encountered and their resolution. Chapter 6 describes the functional and acceptance testing of the software. Chapter 7 concludes with a summary of what has been achieved and the future possible improvements.

Page 10 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2. Literature survey
2.1 Cloud computing
Before talking about the different technologies used in this project, we have to talk about the main purpose for the existence of cloud computing, namely: the simplification of the provisioning of resources. The NIST (National Institute of Standards and Technology of the U.S. Department of Commerce) provides a simple and efficient definition of Cloud computing [9]: Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g. Networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Figure 1: The three usual Cloud Computing layers Source: OVH.com

Usually, Cloud Computing services are dispatched in three categories: SaaS (Software as a Service), hosted software for end users; PaaS (Platform as a Service), turnkey applications environment and IaaS (Infrastructure as a Service), computing resources on-demand. In this report, NIST gives some specific details about this powerful technology that can also be perceived today as a successful business model for the cloud providers as well, since the services are available on-demand by self-service, they are billed with a pay-as-you-go model. This characteristic of cloud computing is one of the most important ones for business start-ups and new users, as the cloud solutions are used for their quick elasticity i.e. their ability to easily handle any load of computing solution. Since these services are designed to be usable by many different users, the provisioning of resources is an enormous challenge in cloud computing. Consequently the use of a federated authentication and authorisation infrastructure is an ideal solution to facilitate this task.

Page 11 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2.2 OpenStack
2.2.1 Introduction to OpenStack
When a company starts to virtualise its infrastructure, it needs to install and configure a hypervisor (e.g. VMWare ESX, Citrix XEN Server, KVM, etc.) [10] on each machine. In this way the resources of each machine are made available as virtual machines (as shown in the diagram below).

Figure 2: Separate resource allocations Source: OpenStack Foundation

The usual second step when the infrastructure grows is to separate the resources into three resources pools and virtualise them separately: servers (CPU, RAM), network and storage; but when these three parts continue to grow and the number of users similarly increases, then what is the best way to manage the provisioning of users? OpenStack is an open source solution developed in Python that provides a cloud computing infrastructure layer designed to efficiently manage all these resources and their users [11]. This project was originally created by NASA and Rackspace in 2010 [12], and is now supported by more than 150 companies [13] through its foundation [14].

2.2.2 The subprojects of OpenStack


Today OpenStack is available in its seventh release, Grizzly [15], and its complete design is based on multiple APIs. All the parts of the project are completely separate and they communicate together by using only these APIs [16]. Each part of the OpenStack project has a code name and specific purpose [17]: Nova [18] [19]: the main project of OpenStack, the compute project that provides an abstraction layer of the compute resources and is able to work with a wide set of available virtualisation technologies. Swift [20] [21]: a highly available and distributed object storage that follows the OpenStack philosophy: all the objects are storable and retrievable using a HTTP RESTful API.

Page 12 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Glance [22]: a discovering, registering and delivering virtual machines images service that uses Swift as the storage service and Nova as the compute service. Quantum [23] [24], recently renamed Neutron [25]: the project that manages the network capabilities of the virtual machines operated by Nova. Horizon [26]: a dashboard that allows users to easily call the different APIs provided by the different OpenStack services, using their web browsers. Keystone [27]: the identity service that provides an authentication and authorisation service for all the OpenStack services. We will focus on this service in this project since our main goal is to simplify the user provisioning by using a Moonshot federated authentication and authorisation service.

2.2.3 OpenStack Keystone


Keystone provides a number of security features from authentication to authorisation, and acts as an entry point to every OpenStack installation. It also acts as a discovery service that allows users to know about all the available services they are able to use. Keystone works as a centralised user authentication system available for all the OpenStack services, and since version 3 of its API, Keystone is designed to support multiple systems of authentication [28].

2.3 Federated identity management


Today, more and more users interact with a lot of different computing services and these services usually require authentication, which increases the number of credentials (typically usernames and passwords) that a user has to retain. This way of deploying services often leads to an increase in maintenance time, a decrease in security, and (for the user) a complicated way of performing identity management. For this reason, most larger organisations tend to adopt a centralised identity management system. Within the same organisational network all the services use a common identity service to authenticate and authorise the different users to use them e.g.: LDAP [29]. Now users only need one set of credentials in order to access all the services of their home organisation. But this does not solve the problem of inter-organisational identity management. This is where the federated identity management design comes in: trust relationships are established between multiple organisational security domains, in which service providers in one domain trust the identity providers in another domain to reliably authenticate and authorise its users. This invariably simplifies the authentication procedure for the users e.g. by using single sign-on (SSO) [30] between the services in different domains. But this requires that the authentication

Page 13 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

flow i.e. the way that users sign-on to a service in one domain without it knowing the credentials of the users, is standardised. There are several existing standardised solutions for federated authentication including: OpenID [8] and SAML [31], but all these solutions as currently implemented 2 require the user to use a web browser during the authentication process. Usually the user has to sign-on to his organisations website (the identity provider) and is then redirected to a given web service page. This protocol flow is not practical in a non-web application context e.g. for authentication against an OpenStack Keystone service. In this case, the Keystone client software has to include a web browser in the client application to allow the user to sign-on on to his/her identity provider website. But federated authentication is not only present at the application layer. Network authentication can be federated too. The best example of this is the academic eduroam [32] network that allows students, researchers and staff to gain access to the Internet at all the campuses participating in the eduroam federation. Eduroam in Europe currently has 37 national-level federations federated together [33], comprising nearly 8000 sites [34]. JANET is the UK federation participant. It is along the idea that we can use virtually the same technologies for application federation, that the IETF ABFAB (Application Bridging for Federated Access Beyond web) [5] protocol specifications are being standardised, and implemented by JANETs Moonshot project.

2.4 Shibboleth
Before describing the ABFAB technology and the value it offers, the best is to study briefly the authentication flow of an existing and widely deployed authentication solution: Shibboleth [35], a federated authentication and authorisation solution based on SAML (see the figure 3 below): 1. The client wants to access to a resource provided by a service provider. The service provider determines the identity provider of the client. 2. The service provider builds a SAML request, redirects the user to his identity provider and passes the SAML request within the redirection. 3. The client identifies itself on the website of his identity provider. 4. The identity provider redirects the user to the original service provider and passes the SAML response within the redirection.

The SAML standard does not require the use of web browser as it has documented several different profiles for federated authentication. However, the web browser profile is the only one that has been widely implemented. Page 14 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

5. The service provider knows the user attributes and is able to give him access to the requested resources.

Figure 3: Federated authentication flow using Shibboleth

2.5 Moonshot
2.5.1 Introduction to Moonshot
Moonshot is a project being lead by Janet [35] (a private UK government-funded organisation that provides computing services to UK research and education). The software is being developed by Painless security [36] a US SME. This project implements the ABFAB protocol suite [5]. The goal of the project is to be able to provide federated authentication to any non-web application and so complete the circle with the existing federated authentication solutions for web-based applications (e.g. Open ID, SAML, etc.). For example, consider a roaming user that wishes to use the local SMTP service of an organisation he is visiting, in order to send an email from the email client installed on his laptop. Assume the SMTP service requires user authentication in order to send the email. The SMTP service cannot use a web-based federated authentication protocol like OpenID without forcing the user to open a web browser alongside his email client, in order to authenticate via the website of his home organisations identity provider. Consequently today, federation does not happen. Instead, the user either has to register for an email account on the local SMTP Page 15 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

service of the visited organisation, or the organisation has to open up its firewall to allow the users email client to contact his home SMTP server. In either case both the SMTP service and the email client need to have access to the users username and password, and have to keep synchronized versions of these credentials. With a non-browser based federated solution, neither system would need to store the users credentials, and the local SMTP server could receive an authentication and authorisation assertion from the users home identity provider. The wish of Janet was to create such an open source non-web federated solution, by making the maximum use of the actual deployed network based federation technologies in use today. Such a solution should be standardised through the normal Internet requests for comments (RFC). This standardisation work is currently being done by the ABFAB (Application Bridging for Federated Access Beyond web) IETF working group.

2.5.2 The Moonshot design and technologies


Moonshot was designed to make maximum use of the existing and widely used technologies, from the authentication flow to the simplification of the implementation into existing applications. First, the principal used ABFAB technology is either RADIUS (the Remote Authentication Dial-In User Service) [6] or DIAMETER (acronym of Remote Authentication Dial-In User Service) [37], alternative protocols that provide an AAA (authentication, authorisation and accounting) service. Since RADIUS technology is already mainly used by eduroam [38] [39], it is the first of these alternative protocols to be implemented in the Moonshot project. For the authentication step, ABFAB uses the Extensible Authentication Protocol (EAP) [7], which perfectly matches the wish to have a direct protocol between the client and the Identity Provider that is relayed by the Service Provider, in our case the OpenStack Keystone service, without requiring the user to be redirected between the two services via a web browser. Again EAP is already used by eduroam [40] to authenticate users across the different network providers. The authorisation part of ABFAB is provided by SAML assertions (the Security Assertion Markup Language), which again are widely implemented throughout Europe in the web based SAML federation protocol. (In the UK this is the protocol used by the UK Access Management Federation.) Identity details about the user are provided in a SAML assertion, which is provided as a RADIUS (or DIAMETER) attribute. On the application side, Moonshot uses the GSSAPI (Generic Security Services Application Program Interface) standard [41], which is used by Kerberos and thus implemented by many existing applications that can potentially easily be moonshoted.

Page 16 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

The goal of Moonshot is thus to use and make all these technologies work together as in the following flow:

Figure 4: Moonshot protocol flow

1. The client application connects to a moonshoted service i.e. a service that implements Moonshot authentication and authorisation. 2. The client needs to authenticate to the service, so it chooses Moonshot: the authentication will be processed by a GSSAPI negotiation between the client and the service. 3. The GSSAPI Moonshot library on the client device invites the user to choose which of his/her identities will be used for the service (See example in the following figure 5). 4. The client provides the users realm e.g. kent.ac.uk, to allow the service (and its radius proxy) to connect it to the appropriate identity provider. 5. A tunnel is established between the client and the identity provider to process the authentication between these two entities. 6. The client sends the users credentials to its identity provider using the secure tunnel: the service and the proxy will never have knowledge of the users credentials. 7. The identity provider returns a success to the moonshoted service and the users authorisation attributes in a SAML assertion.

Page 17 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Figure 5: The Moonshot user interface designed to manage multiple identities

Page 18 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

3. Federated Keystone
3.1 OpenStack Keystone
Traditionally, the OpenStack Keystone Server is designed to manage the authentication and authorisation of local users using different credential storage backends. This service implements the OpenStacks Identity service by providing this service as a combination of different service features [2]: the Identity, Token, Catalog and Policy services. As with all the OpenStack services, all these features are available and administrable via different APIs implemented in different versions over time. The main and stable API is version 2 [42], but we will work on the next version, version 3 [28]. This new API merges the service and administration APIs into a single one, but does not change a lot in the main authentication and authorisation flow as this was designed in version 2. Usually in a non-federated use of Keystone, the first step is to create the local users and groups (provided by the /v3/users and /v3/groups APIs), the different projects (/v3/projects, previously tenant in the API version 2) and the endpoints to the different APIs of the OpenStack services (/v3/endpoints). The second step is to create different roles (/v3/roles), which are used to map the usage rights between users and groups and the different resources (projects, domains). A user is now able to identify itself to the Keystone service and get access to his allocated resources, according to the following flow:

Figure 6: Keystone v3 authentication flow

Page 19 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

1. The client calls the Keystone API with the authentication method (a POST request on /auth/tokens) designed in its third version to support multiple authentication mechanisms at the same time (e.g. A password and a one time password). For example, the client could process a request using the password method with its identity (id) and its password:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "id": "101010", "password": "my_password" } } } } }

The server returns an unscoped token (a token without authorisation) since the client did not specify the required scope. This token is present in the response as an HTTP header X-Subject-Token. The body contains the token details and the user information.
HTTP/1.1 201 Created X-Subject-Token: 4242 { "token": { "issued_at": "2013-06-09T13:02:32.461311s", "extras": {}, "methods": ["password"], "expires_at": "2013-06-10T13:02:32.461279Z", "user": { "domain": { "id": "default", "name": "Default" }, "id": "101010", "name": "vincent@local" } } }

Page 20 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2. The client is now authenticated and may retrieve the list of its projects using the user API (GET /v3/users/{user_id}/projects) and its unscoped token as an HTTP header X-Auth-Token: Request:
GET /v3/users/101010/projects X-Auth-Token: 4242

Response:
HTTP/1.1 200 OK
{ "links": { "self": "http://localhost:5000/v3/users/101010/projects", "previous": null, "next": null }, "projects": [ { "description": "Project one", "links": { "self": "http://localhost:5000/v3/projects/1" }, "enabled": true, "id": "1", "domain_id": "default", "name": "admin" } ] }

Page 21 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

3. Next, the user needs to choose which project or domain he would like to be authorised for, using an authentication request with a specific scope. This time, since the user has already been authenticated, he/she can use the token method with its unscoped token:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": ["token"], "token": { "id": "4242" } }, "scope": { "project": { "id": "1" } } } }

The server returns a scoped token valid for the scope chosen by the user and the endpoints to access the different services:

Page 22 of 59

Providing Moonshot access to OpenStack


HTTP/1.1 201 Created X-Subject-Token: 4343 {

Vincent Giersch vg66@kent.ac.uk

"token": { "methods": ["token", "password"], "roles": [{ "id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_" }], "expires_at": "2013-06-10T13:02:32.461279Z", "project": { "domain": { "id": "default", "name": "Default" }, "id": "1", "name": "admin" }, "catalog": [{ "endpoints": [ { "url": "https://swift.vm:8080/v1/AUTH_1", "region": "RegionOne", "legacy_endpoint_id": "21", "interface": "public", "id": "a086cbc813af4f65a6b91196d90108bf" } ], "type": "object-store", "id": "de6391a46eab441d920eeaa0d73cd8dd" }], "extras": {}, "user": { "domain": { "id": "default", "name": "Default" }, "id": "101010", "name": "vincent@local" }, "issued_at": "2013-06-09T13:37:41.672276" } }

4. The user is now able to use the scoped token to access the different APIs of the services authorised by the issuing Keystone. 5. The OpenStack service checks the validity of the token with the keystone service when the client uses it. Page 23 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

3.2 The Federated Keystone Blueprint


Federated Keystone is a project developed by Kent University and lead by David Chadwick [3], the supervisor of this masters project. The main idea is to create a unified authentication API for all the potential federated protocols that could be integrated into OpenStack Keystone. This blueprint is closely related to the Role Mapping Service blueprint [43] that allows the administrator to define authorisation rules based on the various user identity attributes returned by the different identity providers.

3.2.1 First version API v2


At the beginning of my masters project, the version of Federated Keystone was designed as a middleware of OpenStack Keystone version 2. In this version of the blueprint, for each HTTP request processed in the Keystone service, the middleware checks if the request contains an HTTP header X-Authentication-Type: federated. If this is the case, the middleware catches the request and returns the HTTP response itself.

Figure 7: Federated Keystone designed as a Keystone middleware

The features of OpenStack Federated Keystone v2 are designed as a main core Python class that follows the authentication and authorisation flow, namely: 1. Discovery of the federated protocols that are available: Request body:
{}

Page 24 of 59

Providing Moonshot access to OpenStack Response body:


{

Vincent Giersch vg66@kent.ac.uk

"realms":[ { "id":"8b8dc0af2b9542a183537f852b2db717", "type":"idp.saml", "name":"saml", "description": "SAML protocol" } ] }

realms: An array of the available identity providers. type: The OpenStack endpoint type. The Federated Keystone uses the format idp.* to recognise the federated identity providers ; name: The name of the service ; id: The id of the service ; description: human readable description of the service (optional). 2. Request issuing (e.g. in the case of SAML, Keystone returns to the client a SAML request that should be forwarded to the identity provider): Request body:
{ "realm": { "description": null, "type": "idp.saml", "id": "8b8dc0af2b9542a183537f852b2db717", "name": "saml" } }

realm: The chosen protocol. Response body:


{ "idpRequest": "<SAML-Request>", "idpEndpoint": " http://myidp.co.uk" }

idpRequest: The SAML request that the client has to process against its identity provider ; idpEndpoint: The URL of the identity provider. 3. The negotiation step (this was added specifically for the case of Moonshot since there are several steps required for this negotiation. Most other federation protocols do not have a negotiation step. The design of this step will be described in the next part of this dissertation);

Page 25 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4. The validation step. In the case of SAML, it validates the assertion returned by the identity provider: Request body:
{ "realm": { "description": null, "type": "idp.saml", "id": "8b8dc0af2b9542a183537f852b2db717", "name": "saml" }, "idpResponse": "<SAML Response>" }

idpResponse: The SAML response returned by the identity provider and validated by the Federated Keystone SAML protocol. Response body:
{ "unscopedToken": "1234567890", "tenants": [] }

unscopedToken: The OpenStack unscoped token that can be scoped with a chosen tenant. tenants: The set of authorised tenants that can be used by the client (in the above example, none is authorised).

Figure 8: Federated Keystone v2 designed as a Keystone middleware

Page 26 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

3.2.2 Second version API v3


The second version has been designed to be compatible with the new OpenStack Keystone API version 3 [28] where the authentication methods are available as different plugins and can be combined. These plugins are loaded by the keystone.auth component used as a routing component (this one is only called on the /v3/auth/* routes; thus the federated keystone will be called only when a request is received to use federated authentication, unlike the preceding version where the middleware code was called on each HTTP request processed by the Keystone service).

Figure 9: The Keystone federated authentication plugin

This federated plugin follows the same steps as the second version: discovery, request issuing, negotiation, and validation. It embeds the role mapping service used during the validation step to authorise the client using the identity attributes returned by the identity provider. As in the previous version, federated Keystone [44] embeds the different federated protocols, such as SAML and ABFAB, but each protocol is implemented as a simple Python class (in a similar design to the authentication plugins).

Page 27 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

All the compulsory steps of the authentication process (request issuing, negotiation and validation) are designed in the same way. The optional discovery acting as a catalogue has a different design: 1. Discovery: Request:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": ["federated"], "federated": { "phase": "discovery" } } } }

Response body:
{ "error": { "message": "Additional authentications steps required.", "code": 401, "identity": { "methods": ["federated"], "federated": { "providers": [{ "service": { "url": "<identity provider URL>", "id": "<identity provider identifier>", "name": "<protocol name>" } }] } }, "title": "Unauthorized" } }

Page 28 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2. Request issuing, the negotiation step, and the validation step: Request body:
{ "auth": { "identity": { "federated": { "phase": "(request|negotiation|validate)", "protocol": "<protocol>", "protocol_data": <any protocol specific data>, "provider_id": "<provider-id>" }, "methods": [ "federated" ] } } }

Response body:
{ "error": { "code": 401, "identity": { "federated": { "protocol": "<protocol>", "protocol_data": <any protocol specific data>, "provider_id": "<provider-id>" }, "methods": [ "federated" ] }, "message": "Additional authentications steps required.", "title": "Unauthorized" } }

phase: The federated authentication phase (request, negotiation, or validate) ; protocol: The chose federated protocol (e.g. saml, abfab, etc.) ; protocol_data: The protocol specific data ; provider_id: The identifier of the chosen identity provider.

Page 29 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4. Project design
The main goal of this project is to moonshot the OpenStack Keystone server, so that an OpenStack user can talk directly to his Moonshot identity provider. The Moonshot identity provider (IdP) can be any RADIUS server [6] supporting the EAP authentication mechanisms used and able to return to the service (the OpenStack Keystone server) a SAML assertion [31] containing the users attributes. At the start of the project the following code already existed: - The OpenStack Keystone server and client, written in Python; - The Moonshot project, especially the GSS-EAP Mechanism, written in C, by Painless Security; - The GNU Generic Security Service (libgss) [45], a free implementation of the standardized GSS-API C bindings [46]; To realize the goal, two new functionalities are needed: 1. A GSS-API Python module written in C [47] to allow the OpenStack Keystone server to use the GSS-API C library; 2. A way of transporting the authentication protocol messages over HTTP between the Keystone server and client. The Keystone server and the testing client applications stacks will be composed of four different layers as shown below:

Figure 10: Keystone application stack design

The highest layer is the Keystone server module that will load the new GSS-API Python Bindings module (its design will be explained in the next section). It will use the GSS-API C library [46] to load and communicate with the correct GSS Page 30 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

authentication mechanism (which will be present as a dynamic library identified by an object identifier, OID). The GSS authentication mechanism that we will use is the GSS Moonshot EAP library. This MSc project will be focused on the implementation of the Python-C Bindings module (supporting the Moonshot GSS mechanism) and its integration into Keystone, to allow Keystone to communicate with the GSS C library and the GSS-EAP Moonshot mechanism.

4.1 The GSS-API Moonshot Python Bindings Module


The first part of the work was the design of the Python bindings to the GSS-API C library. This is needed because there is no native GSS-API Python library. However, an open source PyKerberos module was available that was originally developed by Apple. Since Kerberos uses GSS-API then the best approach was to fork the PyKerberos module and adapt the high-level bindings to make them more generic and flexible. This is needed for two reasons: a) to choose the GSS authentication mechanism that will be used (in this case Moonshot), as PyKerberos has hardcoded the choice of Kerberos, and b) to retrieve SAML assertions as a GSS attribute, as Kerberos does not retrieve these. By default, the PyKerberos implementation of the initializing functions only allows the GSS service name (entered as type@fqdn, e.g. keystone@localhost) to be chosen. The choice of authentication mechanism is fixed to Kerberos, but we need it to change to Moonshot. The best possible design, in order to keep the simple functionality of the existing module, was to add a new parameter to allow the Python application to choose the GSS authentication mechanism by its object identifier (OID) viz:
def authGSSClientInit(service, gssflags=GSS_C_MUTUAL_FLAG|GSS_C_SEQUENCE_FLAG, desiredMechOID=None): """ Initializes a context for GSSAPI client-side authentication with the given service principal. authGSSClientClean must be called after this function returns an OK result to dispose of the context once all GSSAPI operations are complete.

@param service: a string containing the service principal in the form 'type@fqdn' (e.g. 'imap@mail.apple.com'). @param gssflags: optional integer used to set GSS flags. (e.g. GSS_C_DELEG_FLAG|GSS_C_MUTUAL_FLAG|GSS_C_SEQUENCE_FLAG will allow for forwarding credentials to the remote host) @param desiredMechOID: the desired mechanism OID, a string representation is a series of blank-separated or period-separated numbers enclosed in braces. (e.g. '{1 3 6 1 5 5 15 1 1 18}') @return: a tuple of (result, context) where result is the result code (see above) and context is an opaque value that will need to be passed to subsequent functions. """

Page 31 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

The second necessary modification was to allow the retrieval of the SAML assertion, returned by the identity provider, as a GSS attribute. As the attributes are available as a set of keys and corresponding values in the GSS C library, the most logical design was that the Python-C binding would return the set as a dict in Python [48].
def authGSSServerAttributes(context): """ Get the attributes (implementation of gss_inquire_name and gss_get_name_attribute) This method must only be called after authGSSServerStep returns a complete.

@return: a dict with the attributes """

Page 32 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4.2 The HTTP API Design


The second main part of the design work was the HTTP API to transport the GSS-API authentication messages between a client and the OpenStack Keystone server. The design had to fit with the Federated Keystone Blueprint API and at the same time to follow the GSS authentication flow. The main modification of the Federated Keystone protocol was the addition of the negotiation step. This is required by the GSS authentication flow to choose the GSS mechanism between the server and the client [49], and process the different steps of the GSS EAP Moonshot authentication protocol.

4.2.1 First version API v2


When the project started, the Moonshot implementation was designed for federated keystone V2 i.e. where the processing was in the middleware. In this design the Moonshot authentication had to follow this flow: 1. Discovery: The client retrieves the list of the available federated authentication providers, returned as a list comprising the identity providers ID, name and type (of format idp.{name}). Request body:
{}

Response body:
{ "realms":[ { "id":"36fe70842e2d47a0a9667f401fb5f9c0", "type":"idp.moonshot", "name":"moonshot", "description": null } ] }

realms: An array of the available identity providers. type: The OpenStack endpoint type. The Federated Keystone uses the format idp.* to recognise the federated identity providers ; name: The name of the service ; id: The id of the service ; description: human readable description of the service (optional).

Page 33 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2. Request issuing: The client chooses Moonshot as the authentication system. Request body:
{ "realm": { "description": null, "type": "idp.moonshot", "id": "36fe70842e2d47a0a9667f401fb5f9c0", "name": "moonshot" } }

realm: The chosen federated identity provider. Originally, the federated protocol was designed for an authentication using SAML, thus the response here contained the SAML request that the client had to process (idpRequest) against its identity provider (idpEndpoint). SAML example response body:
{ "idpRequest": "<saml-request>", "idpEndpoint": " http://myidp.co.uk" }

Since Moonshot authentication is a GSS negotiation, the client does not process any request on its side. Therefore in this API version, the idpEndpoint parameter has been used to return the information of the GSS service (this design has been improved in the third and current version): Response body:
{ "idpRequest": null, "idpEndpoint": { "serviceName": "keystone@moonshot", "mechanism": "{1 3 6 1 5 5 15 1 1 18}" } }

idpRequest: The request that the client has to process against its identity provider (e.g. in the usage of an authentication using SAML). Here this parameter is empty since the authentication is a GSS negotiation. idpEndpoint: Parameters for the GSS authentication: serviceName: The GSS service name ; mechanism: The OID mechanism desired by the service (here is eapaes256).

Page 34 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

3. The negotiation step: The client proceeds to communicate with the Keystone server through the GSS-API negotiation phase, and the GSS-API EAP Moonshot module in federated Keystone manages the connection to, and authentication with, the remote identity provider (see the Moonshot technology details section 2.4.2). The HTTP API will simply transport the GSS-API messages generated by the client and the Keystone server. This step is repeated for each step of the negotiation; the client has to use a HTTP keep-alive connection to allow the server to keep the GSS context all along the negotiation. The client communicates with the Identity Provider through Keystone, the negotiation is sent as an idpNegotiation to Keystone. Request body:
{ "idpNegotiation": "YCYGCSsGAQUFDwEBEgYBA==", "realm": { "description": null, "type": "idp.moonshot", "id": "36fe70842e2d47a0a9667f401fb5f9c0", "name": "moonshot" } }

idpNegotiation: This contains the GSS-API message returned by the client and to be transported to the IdP via Keystone. realm: The identification of the federated protocol and IdP to be used. Response body:
{ "idpNegotiation": "YBsGCSsGAQUFDwEBEgYCgAAABQAAAAYBAQAGA=" }

idpNegotiation: This contains the next message from the IdP to the client.

Page 35 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4. The validation step: The final request sent by the client asks the Keystone server for an unscoped token and the tenants list, in a similar way to a nonfederated authentication request (and the non-federated authentication flow). Request body:
{ "realm": { "description": null, "type": "idp.moonshot", "id": "36fe70842e2d47a0a9667f401fb5f9c0", "name": "moonshot" }, "idpResponse": null }

Here, idpResponse is empty since in the ABFAB protocol the client does not need to return the IdPs response to the Keystone service, as it is already in possession of the SAML assertion. Response body:
{ "unscopedToken": "1234567890", "tenants": [] }

unscopedToken: The OpenStack unscoped token that can be scoped with a chosen tenant. tenants: The set of authorised tenants that can be used by the client (in the above example, none is authorised). 5. If the client is authorised to access to a service, it is now able to scope its token using the regular Keystone v2 API and then access the chosen service.

Page 36 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4.2.2 Second version API v3


Several weeks later, the design of Federated Keystone changed to follow the design of the Keystone v3 API. The Moonshot protocol design had to evolve to be a protocol inside the federated authentication plugin and to follow the Keystone API v3 design. The following design may change during the design review of the identity API [51] [51]. The following content corresponds to the implementation contained in the corpus of this MSc project. 1. Discovery: The client retrieves the list of the federated protocols available using the discovery service. This time, the request fits the API v3 design: the client specifies that he wants to use the federated authentication plugin and the phase of authentication is set to discovery. The OpenStack Keystone server returns the available protocols as an array of service endpoints. Request:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": ["federated"], "federated": { "phase": "discovery" } } } }

Response body:
{ "error": { "message": "Additional authentications steps required.", "code": 401, "identity": { "methods": ["federated"], "federated": { "providers": [{ "service": { "url": "", "id": "36fe70842e2d47a0a9667f401fb5f9c0", "name": "abfab" } }] } }, "title": "Unauthorized" } }

Page 37 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

2. Request issuing: The client now needs the Moonshot protocol details i.e. the GSSname of the Keystone service and its preferred GSS authentication mechanism OID. The client specifies to the Keystone server that this is the request issuing phase, and this fetches the request details that the client will process on its side. Request:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": [ "federated" ], "federated": { "phase": "request", "provider_id": "36fe70842e2d47a0a9667f401fb5f9c0", "protocol": "abfab" } } } }

Response body:
{ "error": { "message": "Additional authentications steps required.", "code": 401, "identity": { "methods": [ "federated" ], "federated": { "provider_id": "36fe70842e2d47a0a9667f401fb5f9c0", "protocol": "abfab", "protocol_data": { "service_name": "keystone@moonshot", "mechanism": "{1 3 6 1 5 5 15 1 1 18}" } } }, "title": "Unauthorized" } }

provider_id: The identifier of the identity provider. In the ABFAB authentication, this identifier is unique since the choice of the identity provider is not managed at the level of OpenStack. Page 38 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

protocol: The federated protocol used, here abfab ; protocol_data: The protocol-specific information: o service_name: The GSS service name of the Keystone service; o mechanism: The OID of the authentication mechanism desired by the service (here is eap-aes256). 3. The negotiation step: The client is now able to conduct a GSS-API negotiation using Moonshot/EAP authentication, in a similar way to the previous design. During this repeated step, the client and the Keystone server exchange the GSS-API messages. As in the API version 2, the client has to use a HTTP keep-alive connection to allow the server to keep the GSS context until the next step. In the second version of the Federated Keystone and the ABFAB protocol module, the client was identified to the module all along the GSS negotiation by its IP address and port. However, since this module does not have access to the connection details (the IP address and port of the client), a client identifier (cid) is generated by the module and the client sends it within each negotiation request. The federated keystone module uses this identifier to associate the GSS message to the GSS negotiation context. Request:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": [ "federated" ], "federated": { "phase": "negotiate", "provider_id": "36fe70842e2d47a0a9667f401fb5f9c0", "protocol": "abfab", "protocol_data": { "negotiation": "YCYGCSsGAQUF==", "cid": null } } } } }

negotiation: The GSS message ; cid: The client identifier.

Page 39 of 59

Providing Moonshot access to OpenStack Response body:


{

Vincent Giersch vg66@kent.ac.uk

"error": { "message": "Additional authentications steps required.", "code": 401, "identity": { "methods": [ "federated" ], "federated": { "provider_id": "36fe70842e2d47a0a9667f401fb5f9c0", "protocol": "abfab", "protocol_data": { "negotiation": "YDoGCSsGAQUFDwh", "cid": "aea885aa-dfcd-11e2-b3c3-000c296102eb" } } }, "title": "Unauthorized" } }

Page 40 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4. The validation step: The client is now identified with its identity provider through Keystone and is able to retrieve an unscoped token, returned as a HTTP header X-Subject-Token. Request:
POST /v3/auth/tokens
{ "auth": { "identity": { "methods": [ "federated" ], "federated": { "phase": "validate", "provider_id": "36fe70842e2d47a0a9667f401fb5f9c0", "protocol": "abfab", "protocol_data": { "cid": "aea885aa-dfcd-11e2-b3c3-000c296102eb" } } } } }

Response:
HTTP/1.1 201 Created X-Subject-Token: 4242 { "token": { "issued_at": "2013-06-28T08:52:13.250298Z", "extras": {}, "methods": ["federated"], "expires_at": "2013-06-29T08:52:13.250269Z", "user": { "domain": { "id": "default", "name": "Default" }, "id": "6e66e97f002f47d0bc364afb28aa6467", "name": "10d2dec8e5fe9dadbd47f6272410b8f795b8046d" } } }

5. The user is now allowed to scope his token, in a similar way to a classical password authentication using the Keystone API v3. Page 41 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4.3 Python module design


4.3.1 First version
The first version of the design of the Python Federated Keystone Moonshot protocol follows the design of any other federated keystone protocol: The request issuer service will return the details of the Moonshot protocol. The Negotiator service will receive the GSS messages from the client and send the GSS server message to it. The Credential validator service will retrieve the username and the SAML assertion from the IdP once the negotiation is done and will check the validity of these attributes with the issuing policy API [44].

4.3.2 Second version


The second version of the Python module is almost the same regarding the three parts specified above. The only significant change is the grouping of these three Python classes into a single one.

Page 42 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

5. Project implementation
5.1 A Python module for Moonshot
The implementation work for the C module consisted of two steps. Firstly, studying the standard of the GSSAPI C bindings [46] and then carrying out the implementation of the GSSAPI test server and client [53] to find how to implement the needed modifications to the PyKerberos library. The first part of the implementation, adding the desired mechanism to the two Python functions authGSSClientInit and authGSSServerInit consisted of parsing the new additional Python string, to convert the const char* as a gss_OID type using the gss_str_to_oid() C function, to store the preference in the server or client state structure (seen as an opaque variable in Python), which will be used for all calls to the gss_init_sec_context() C function. The second part was to add a new Python function authGSSServerAttributes to return the GSS attributes. Since there are no string keys in a C array, the C GSS bindings for this feature are designed by using two C functions: gss_inquire_name() and gss_get_name_attribute(), that return an array of attributes keys and the value of an attribute, respectively. In this way, the C code of this new Python binding was designed to create a dict that contains these two sets of information.

5.2 The Federated Keystone protocol: Moonshot


5.2.1 First version
The implementation of the federated keystone protocol consisted of four Python classes: 1. RequestIssuingService: This class returns the details of the Moonshot protocol; specifically the GSS service name for Keystone and the preferred authentication mechanism OID. The core of the Federated Keystone calls this class when a client chooses Moonshot as the authentication protocol. 2. Negotiator: This class initializes the GSS negotiation and at each step of the negotiation receives a GSS message from the client, communicates it to the authGSSServerStep function and retrieves the response for the client with authGSSServerResponse, which are two functions of the Python Moonshot module. 3. CredentialValidator: This class processes the last API call (once the negotiation is completed), retrieves the username and the SAML assertion corresponding to the clients authorisation, cleans the GSS clients context and returns the details of the client to the core of the federated keystone.

Page 43 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

4. GssAPIContext: This is a helper class designed to help the management of the different GSS client contexts (an opaque Python variable that contains on the C side, a structure with different elements identifying the client and his authentication status). The Negotiator and CredentialValidator classes inherit from the class that manages the static storage of the GSS contexts. These child classes use this class to store or retrieve from memory a GSS context using the key identifying the client (in this version, a hash of the IP and the port of the client). This class therefore acts as a simple key / value storage in memory. One of the main problems of the implementation was keeping the continuity of a GSS context throughout the series of negotiation steps. In fact, Keystone is based on the WSGI model in which the server processes client requests separately without having a notion of a connection [54]. To process a WSGI request, the server provides environment information and a callback function to the client, for it to use in the next call, whereas GSS implementations like in Apache use a Keep-Alive connection to identity the requests of the same client. In the WSGI design, it is impossible to know if a client has abandoned the negotiation since there is no hook for closing the socket. The best workaround used (operated by the GssAPIContext class) was to store all the contexts in a Python dict with keys based a unique client identifier (in this version, the IP and port used by the client during the negotiation). It was also necessary to add an expiration time for the potential abandoned connections and to clean the expired contexts regularly.

5.2.2 Second version


The Python module implementation is simpler than the fist version since there is a single class and no inheritance (implemented in the previous version by the class GssAPIContext). This class includes different methods to manage the GSS-API contexts and the three phases of the authentication: request issuing, negotiation and validation. The GSS contexts were previously associated to a client with its IP and connection port. In this second version, the authentication plugin does not have access to the connection details. So the only way to track the requests of the same client in a single session was to generate a unique client identifier to act as a session key. In the final implementation we used a UUID for this purpose [55].

Page 44 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

6. Testing and validation


The testing of this project was split into two phases. The first was the functional testing which consisted of writing unit tests, and running these alongside existing tests in the Keystone repository. A minimalist software environment was used for these tests. This stage of testing was to check that all the software features were working well. The second part was the acceptance testing (the integration of our software in an environment designed to validate our original objectives).

6.1 Functional testing


For the purpose of testing the new Moonshot authentication capability, the first testing phase was to write new functional tests for Keystone. The required testing environment should include a RADIUS proxy with at least one identity, the Moonshot libraries and a Keystone developing environment [56]. The easiest way to setup this environment was to use an installation based on the Moonshot live DVD [57]: a Debian wheezy including a RADIUS server, the Moonshot libraries and the different existing integrations of the Moonshot authentication. The purpose of these tests is to validate that all the potential use cases are working well, including all the different potential fraudulent inputs or error cases checked by the Moonshot authentication protocol module. This ensured good coverage of the server code written during this project. The functional tests act as an OpenStack client that makes requests and calls the different modules of Keystone. The functional tests developed: Test if the request includes a valid authentication phase; Test the discovery phase; Test the request issuing phase; Test the negotiation phase with a missing or bad client identifier, with a missing or bad negotiation string; Test the validation phase with a missing or bad client identifier; Try to validate the authentication with a not completed negotiation; Test the complete process of authentication.

6.2 Acceptance testing


The acceptance-testing step had to be designed so that it could determine that the software fulfils the original objectives specified in the introduction of this dissertation.

6.2.1 An OpenStack testing client


To achieve the acceptance tests it was necessary to use a real client that can have access to some OpenStack resources. The best choice here was to develop a Page 45 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Moonshot protocol client module for the python-swiftclient because this client already includes the federated keystone implementation and the existing implemented protocols (namely: SAML and Keystone v2 identity provider). The swift client was enhanced to implement the Moonshot protocol in the two different versions of the federated Keystone API (2nd and 3th).

6.2.2 Planning of the infrastructure setup


Since the Moonshot project is still at the beginning of the pilot phase, there is no operational Moonshot federated infrastructure setup yet. In order to conform to the objectives, the requirements dictated that two different domains with two different RADIUS servers were setup, each handling one realm (see Figure 11 below).

Figure 11: The final step of the setup of the acceptance testing

On the OpenStack side, the idea was to add the Moonshot protocol alongside the other federated protocols of the federated Keystone, especially SAML which provides web-based federated authentication. The best solution was to use an existing setup of OpenStack (fedkeystone.sec.cs.kent.ac.uk) that provides a demonstration of the federated keystone and configure the Moonshot protocol with the kent.ac.uk domain. This virtual machine is based on DevStack [58] and provides therefore all the different existing OpenStack services.

Page 46 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

6.2.3 A Freeradius rlm_python module


Since the plan was to use two different LDAP backends (the LDAP in production of the University of Kent and a testing LDAP, respectively in two different domains, kent.ac.uk and sec.cs.kent.ac.uk) for the two RADIUS servers and it was desirable to return SAML assertions without configuring two different SAML Identity providers, the easier and faster way was that the RADIUS servers could build the SAML assertions themselves once the users have been authenticated. To realise this idea, the most efficient way was to create a Python module that would be called by the rlm_python Freeradius module [59]. This Freeradius module allows people to write Freeradius modules in Python by running them in a Freeradius environment: the Freeradius server will execute this module once the authentication is done to build the authorisation response (a SAML assertion). The module was designed to use the elements from the Freeradius environment (the username stripped of the domain and the user password), to search for the user in the LDAP backend. Then it logs in as the user to the backend and thus is able to fetch all his attributes. Finally it builds a SAML assertion using the PySAML2 [60] library and returns it as a RADIUS attribute, SAML-AAA-Assertion. One problem that was encountered was the return of the built assertion since the maximum length of a RADIUS attribute is 255 bytes, and the maximum length of a RADIUS packet is 4096 bytes. A too longer RADIUS attribute or packet would generate an empty authorisation on the Keystone or would crash the Freeradius server. The chosen solution was to remove the unused users attributes and send only the used attributes by Keystone (e.g. only the group of the user) and thus fit the reply into a RADIUS packet. The issue of the attribute length was resolved by splitting the assertion into several RADIUS attributes of a smaller size (less than 255 bytes).

Page 47 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

6.2.4 First step of the setup: a single domain, sec.cs.kent.ac.uk


The first step of the setup was to have a functional authentication inside a single domain, illustrated in the figure 10 below.

Figure 12: The first step of the setup of the acceptance testing

In this first test (see figure 12 above and 13 below), a user of the domain sec.cs.kent.ac.uk has a terminal inside its domain with a moonshoted OpenStack client and the Moonshot client. This one is able to authentication itself against its identity provider (the couple Freeradius and LDAP) and access to the allowed resources on the OpenStack infrastructure within its domain.

Figure 13: Authentication flow for a user of sec.cs.kent.ac.uk

This authentication is processed between the Moonshot client and the Freeradius server. The connection is encrypted (see figure 13 above) using the EAPTTLS protocol (EAP-Tunneled Transport Layer Security). This is an EAP [7] protocol that uses TLS to create a secure tunnel between the client and the RADIUS authentication server. The RADIUS server (see figure 13 above) will handle a new connection, check the realm of the user (in our case @sec.cs.kent.ac.uk, the first domain of the infrastructure), and transport the connection to a second RADIUS site, innertunnel. Only this second site will know the username and password of the different Page 48 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

users, process the authentication and return the SAML assertion to the first RADIUS site (outer-tunnel). The authentication in the tunnel will be processed in EAP-GTC since in this acceptance test we are not an administrator of the credentials backend (LDAP), and the only way to check that the authentication is valid is to authenticate ourselves against the LDAP backend; thus the RADIUS server needs the clear text password. Since the testing made use of an LDAP testing service that was already setup for this domain, the organisation TAAS was chosen because it perfectly matched the needs: two different levels of rights, student and PhD that will have access to two different projects in the testing OpenStack infrastructure. The Keystone service will map this user attributes to the OpenStack projects and roles using the mapping API [44] and provision the correct authorisation to the different users.

6.2.5 Second step of the setup: multiple domains


The second main step was to add a second domain whose users will be able to connect to our OpenStack infrastructure. The choice here was to use the kent.ac.uk realm since the users of this domain are already able to use the demonstration Federated Keystone using the federated SAML protocol. Here, the idea is to allow them to authenticate against the Keystone service by using a second non-web authentication solution, Moonshot. Since the two federated keystone protocols return the same user identity attributes in two different ways, we can give them the same authorisation and thus the same access to the OpenStack resources. This second step only required configuration of a second RADIUS server. The first RADIUS server will receive a connection using the EAP-TTLS protocol, will recognise the user realm, @kent.ac.uk and will simply forward this EAP-TTLS connection to a second RADIUS server handling the kent.ac.uk domain. This is the same flow and configuration as an authentication with the @sec.cs.kent.ac.uk realm except the connection will be forwarded to the second RADIUS server instead of the inner-tunnel RADIUS site of the first RADIUS server. In the figures 11 and 14, the new map of the service is schematized in the 11 and the authentication flow in the figure 14.

Page 49 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

Figure 14: Authentication flow of a user of kent.ac.uk

The users who are Kent staff can gain access to additional resources that other users (Kent student) cannot. The rights are the same as those provided by the SAML authentication: the Keystone mapping service checks that users have the attribute unikentaccounttype to give access to the first part of resources and checks its value (staff) to give access to the second part of the resources.

6.2.6 Acceptance tests 6.2.6.1 Within the same domain


A student or PhD student at a terminal of the domain sec.cs.kent.ac.uk tries to access to the Keystone of its domain. The Keystone service gives to him the GSS service details and his OpenStack client starts a GSS negotiation with the Keystone Service. He is invited to enter his credentials in the Moonshot identity manager and the Moonshot GSS library initializes the EAP connection by sending its domain, sec.cs.kent.ac.uk, to the RADIUS server of the domain sec.cs.kent.ac.uk. This RADIUS server checks the domain and recognises a local domain. The EAP client negotiates an EAP-TTLS tunnel with the RADIUS server and authenticates with the inner-tunnel RADIUS server using EAP-GTC. This RADIUS server returns the user attributes to the Keystone service. The Keystone Service maps the attributes and allocates the authorised resources to the user. The user is able to access to his Swift container.

6.2.6.2 Between two domains


A student or a member of staff at a terminal in the domain kent.ac.uk tries to access to the Keystone service of the domain sec.cs.kent.ac.uk.

Page 50 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

The Keystone service gives to him the GSS service details and his OpenStack client starts a GSS negotiation with the Keystone Service. He is invited to enter his credentials in the Moonshot identity manager and the Moonshot GSS library initializes the EAP connection by sending its domain, kent.ac.uk, to the RADIUS server of the domain sec.cs.kent.ac.uk. This RADIUS server checks the domain and opens a connection on the trusted RADIUS server of the domain kent.ac.uk. The EAP client negotiates an EAP-TTLS tunnel with its RADIUS server kent.ac.uk, and authenticates with the inner-tunnel RADIUS server using EAP-GTC. This RADIUS server returns the user attributes to the RADIUS server of the domain sec.cs.kent.ac.uk, which returns them to the Keystone service. The Keystone Service maps the attributes and allocates the authorised resources to the user. The user is able to access to his Swift container.

6.2.7 Summary of these tests


The setup infrastructure fulfils the original objectives of the project: 1. It is now possible to use the OpenStack services of the federated keystone demonstration infrastructure using Moonshot and thus have access to them without using a web browser. The federated access is provided by conforming to the ABFAB protocol suite [5]. The testing architecture follows the architectures specification draft [61] and uses the GSS-API EAP (Extensible Authentication Protocol) mechanism [62]. The non-implemented ABFAB elements in these acceptance tests are: a. The use of a SAML server: this is replaced by a RADIUS module, and b. The use of a "trust router: since this will eventually be hosted by JANET. The goal of this project is to validate the Moonshot software for federated authentication, and not validate the federated infrastructure itself. 3. In the acceptance tests, the users of the kent.ac.uk domain can access the OpenStack services of the sec.cs.kent.ac.uk with two different access levels. In the same way, the sec.cs.kent.ac.uk users can access to the same OpenStack services within their domain, with two different access levels.

2.

4.

Page 51 of 59

Providing Moonshot access to OpenStack 5.

Vincent Giersch vg66@kent.ac.uk

An administrator of this OpenStack architecture can configure different mapping rules to automatically provide resources for the users: the mapping is between the attributes returned by the users identity provider and the roles defined in OpenStack.

Page 52 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

7. Conclusion
This project is the integration of two brilliant technologies: OpenStack, an open source cloud technology that is deployed and used more and more often every day, and Moonshot/ABFAB which blends several other powerful authentication technologies in a smart way. This project allowed gave the author the chance to work on this project, to study the details of OpenStack Keystone, to discover the IETF ABFAB/Moonshot technologies which are still under development, and it was really an enjoyable experience to make these two technologies function together. The two final versions work well and meet the original objectives of this project: providing a non-web federated authentication in OpenStack using the ABFAB protocol suite [5], implemented by the Moonshot project. As OpenStack is an open source project, the code of this project has been released under the license terms of the OpenStack project and is available online to anyone who wants more information about this project [63]. A demonstration of this project is available on the Federated Keystone demonstration page, setup as mentioned in the acceptance testing part [64].

7.1 Current limitations


The only issue in the current implementation of the Moonshot authentication in OpenStack Keystone is the way to keep the GSS-API context live throughout the authentication exchange and to effectively clean the contexts of any abandoned authentication attempts. The current design is flawed because of the usage of a WSGI designed HTTP server in Keystone. This means that there is no good way to bind a GSS context to a HTTP connection and receive notification when the TCP socket is closed so that the GSS context can then be destroyed. Adam Young, a core developer of OpenStack Keystone, has noticed this limitation last year and proposed a move to Apache HTTPd [65]. The proposed solution for the Havana release was the integration of an authentication plugin that supports an external authentication [66], so it requires the utilisation of a reverseproxy to authenticate the user and pass the username through an environment variable to Keystone. This solution works with the Moonshot Apache module, but there would be no dynamic provisioning and no way to get the attributes of a user. Only the authentication of a user who already exists in the Keystone system can be done in this way. The client implementation is also limited. In order to conduct the acceptance tests, the Moonshot authentication protocol was only implemented in the pythonswiftclient, and not in any of the other OpenStack clients. But this client will disappear in the next release and will be replaced by a unified OpenStack client. However this was still in development at the end of this project, so it was not possible to integrate Moonshot into it.

Page 53 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

More broadly, Moonshot authentication was not implemented in all the existing OpenStack clients since they do not support the third version of the Keystone API and are not designed with authentication plugins.

7.2 Further research


Possible further research would be into a compromise between the two solutions above, either a change of design in the web server or an improvement of the Moonshot and the external authentication modules. A change of design in the web server could provide a way to hook a function at any step of TCP connection or HTTP request and thus have a real link between the GSS context and the client: its connection. This second solution would be the easier to implement because the only thing to do would be to export the SAML authorisation assertion into an environment variable. Then the mapping API in the external authentication plugin could be used to provide the same provisioning as the federated Keystone. Other further research would be to modify the main OpenStack clients to have an authentication design based on standard plugins. This would open up the opportunity to be able to develop a single plugin that could be used with any OpenStack client.

Page 54 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

8. References
[1] Openstack Foundation. (2013) OpenStack. [Online]. http://www.openstack.org/foundation/companies/ [2] OpenStack LLC. (2013) OpenStack. [Online]. http://docs.openstack.org/developer/keystone/ [3] David Chadwick. (2013, Apr.) OpenStack. [Online]. https://wiki.openstack.org/wiki/Keystone/Federation/Blueprint [4] Kristy Siu. (2013) Federated OpenStack Keystone: v2 implementation. [Online]. https://github.com/kwss/keystone/tree/kent-federated-april [5] IETF working group: ABFAB. (2013) IETF - Application Bridging for Federated Access Beyond web. [Online]. http://datatracker.ietf.org/wg/abfab/ [6] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)," IETF, RFC 2865 2000. [7] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)," IETF, RFC 3748 2004. [8] Brad Fitzpatrick, David Recordon, Dick Hardt, and Josh Hoyt. (2007, Dec.) OpenID. [Online]. http://openid.net/specs/openid-authentication-2_0.html [9] Peter Mell and Timothy Grance, "The NIST Definition of Cloud Computing," National Institute of Standards and Technology, U.S. Department of Commerce, NIST Special Publication 800-145, 2011. [10] Karen Scarfone, Murugiah Souppaya, and Paul Hoffman , "Guide to Security for Full Virtualization Technologies," National Institute of Standards and Technology, U.S. Department of Commerce, Special Publication 800-125, 2011. [11] OpenStack Foundation. (2013) OpenStack. [Online]. http://www.openstack.org/software/ [12] Rackspace. (2010, July) Rackspace. [Online]. http://www.rackspace.com/blog/newsarticles/rackspace-open-sources-cloudplatform-announces-plans-to-collaborate-with-nasa-and-other-industryleaders-on-openstack-project/ [13] OpenStack Foundation. OpenStack. [Online]. http://www.openstack.org/foundation/companies/ [14] Lauren Sell. (2012, Sep.) OpenStack Launches as Independent Foundation, Begins Work Protecting, Empowering and Promoting OpenStack. [Online]. http://www.businesswire.com/news/home/20120919005997/en/OpenStackLaunches-Independent-Foundation-Begins-Work-Protecting [15] OpenStack Foundation. OpenStack Wiki. [Online]. https://wiki.openstack.org/wiki/GrizzlyReleaseSchedule [16] OpenStack Foundation. OpenStack. [Online]. http://docs.openstack.org/api/quick-start/content/ [17] Ken Pepple. Solinea. [Online]. http://www.solinea.com/2013/06/15/openstackgrizzly-architecture-revisited/ [18] OpenStack Foundation. Nova developer documentation. [Online]. http://docs.openstack.org/developer/nova/ Page 55 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

[19] OpenStack Foundation. OpenStack Compute. [Online]. http://www.openstack.org/software/openstack-compute/ [20] OpenStack Foundation. Swift developer documentation. [Online]. http://docs.openstack.org/developer/swift/ [21] OpenStack Foundation. OpenStack Storage. [Online]. http://www.openstack.org/software/openstack-storage/ [22] OpenStack Foundation. Glance developer documentation. [Online]. http://docs.openstack.org/developer/glance/ [23] OpenStack Foundation. OpenStack Networking Administration Guide. [Online]. http://docs.openstack.org/trunk/openstack-network/admin/content/index.html [24] OpenStack Foundation. OpenStack. [Online]. http://www.openstack.org/software/openstack-networking/ [25] Russell Bryant. (2013, June) Twitter. [Online]. https://twitter.com/russellbryant/status/347099566765658113 [26] OpenStack Foundation. OpenStack. [Online]. http://www.openstack.org/software/openstack-dashboard/ [27] OpenStack Foundation. OpenStack Keystone developer documentation. [Online]. http://docs.openstack.org/developer/keystone/ [28] OpenStack Foundation. (2013, June) OpenStack Identity API v3. [Online]. https://github.com/openstack/identity-api/blob/master/openstack-identityapi/v3/src/markdown/identity-api-v3.md [29] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory Access Protocol," IETF, RFC 1995. [30] S.S.Y. Shim, Geetanjali Bhalla, and Vishnu Pendyala, "Federated identity management," Computer, vol. 38, no. 12, Dec. 2005. [31] Scott Cantor, John Kemp, Rob Philpott, and Eve Maler. (2013, May) SAML Specifications. [Online]. http://saml.xml.org/saml-specifications [32] Eduroam. TERENA Eduroam. [Online]. https://www.eduroam.org/ [33] TERENA. eduroam Europe - eduroam Service Coverage. [Online]. https://www.eduroam.org/?p=europe [34] Eduroam US. eduroam International Map. [Online]. https://www.eduroam.us/eduroam_international_map [35] The Shibboleth Consortium. (2013) Shibboleth. [Online]. http://shibboleth.net/ [36] Janet. Janet. [Online]. https://community.ja.net/groups/moonshot [37] Painless Security. (2010, Feb.) Painless Security. [Online]. http://www.painlesssecurity.com/blog/2010/02/12/moonshot1 [38] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, "Diameter Base Protocol," IETF, RFC 3588. [39] Janet. Janet. [Online]. https://www.ja.net/products-services/janetconnect/eduroam [40] Eduroam US. Eduroam.us. [Online]. https://www.eduroam.us/radius_configuration [41] TERENA. Eduroam. [Online]. https://www.eduroam.org/index.php?p=faq

Page 56 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

[42] L. Zhu, K. Jaganathan, and S. Hartman, "The Kerberos Version 5 - Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2," IETF, RFC 4121 2005. [43] OpenStack Foundation. (2013) OpenStack documentation. [Online]. http://docs.openstack.org/api/openstack-identity-service/2.0/content/ [44] Kristy Siu. (2012, Nov.) A Role Mapping Service for the Keystone Identity Server. [Online]. https://blueprints.launchpad.net/keystone/+spec/role-mappingservice-keystone [45] Free Software Foundation Simon Josefsson. GNU Generic Security Service Libgss. [Online]. http://www.gnu.org/software/gss [46] J. Wray, "Generic Security Service API Version 2 : C-bindings," IETF, RFC 2744 2000. [47] The Python Software Foundation. Python/C API Reference Manual. [Online]. http://docs.python.org/2/c-api/ [48] The Python Software Foundation. The Python Standard Library. [Online]. http://docs.python.org/2/library/stdtypes.html#dict [49] J. Linn, "Generic Security Service Application Program Interface, Version 2," IETF, RFC 2078 1997. [50] David Chadwick. (2013, Aug.) OpenStack Review: Documentation for Authentication Plugin for Federations. [Online]. https://review.openstack.org/39499 [51] Vincent Giersch and David Chadwick. (2013, Aug.) OpenStack Review: ABFAB profile for federated authentication plugin. [Online]. https://review.openstack.org/42221 [52] OpenVision. (1993) Github. [Online]. https://github.com/krb5/krb5/tree/master/src/appl/gss-sample [53] The Python Software Foundation. The Python Standard Library. [Online]. http://docs.python.org/2/library/wsgiref.html [54] P. Leach, M. Mealling, and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace," IETF, RFC 4122. [55] OpenStack Foundation. (2012) Developing with Keystone. [Online]. http://docs.openstack.org/developer/keystone/developing.html [56] Rhys Smith. (2013, June) JANET - Getting started with Moonshot - Using the Live DVD. [Online]. https://community.ja.net/groups/moonshot/wiki/gettingstarted-moonshot-using-live-dvd [57] The Openstack Foundation. DevStack. [Online]. http://devstack.org/ [58] Arran Cudbard-Bell. Freeradius - rlm_python. [Online]. http://wiki.freeradius.org/modules/Rlm_python [59] Roland Hedberg. PySAML2. [Online]. https://pypi.python.org/pypi/pysaml2/ [60] J. Howlett, S. Hartman, H. Tschofenig, E. Lear, and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) - Architecture," IETF, RFC Draft. [61] S. Hartman, Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol," IETF, RFC Draft. Page 57 of 59

Providing Moonshot access to OpenStack

Vincent Giersch vg66@kent.ac.uk

[62] Vincent Giersch. OpenStack Keystone sources. [Online]. https://github.com/gierschv/keystone/tree/moonshot-v3 [63] Kristy Siu. (2103) A Federated Keystone Identity Server - Demonstration. [Online]. http://sec.cs.kent.ac.uk/demos/keystone.html [64] Adam Young. (2012) Keystone should move to Apache HTTPD. [Online]. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ [65] Adam Young. (2013) Pluggable handling of REMOTE_USER. [Online]. https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user [66] Janet. Janet. [Online]. https://www.ja.net/about-janet/about-us [67] Ed. A. Melnikov, "The Kerberos V5 ("GSSAPI") - Simple Authentication and Security Layer (SASL) Mechanism," IETF, RFC 4752 2006.

Page 58 of 59

9. Appendix 1: Architecture of OpenStack Grizzly

Figure 15: Conceptual schema of the OpenStack Grizzly architecture - Source Solinea.com

Page 59 of 59