Professional Documents
Culture Documents
Page 1 of 59
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
Acknowledgments
I would like to thank David Chadwick and Kristy Siu for their help and support during this masters project.
Page 3 of 59
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!
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
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
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
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
Page 9 of 59
Page 10 of 59
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.
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
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).
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].
Page 12 of 59
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.
Page 13 of 59
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
5. The service provider knows the user attributes and is able to give him access to the requested resources.
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
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.
Page 16 of 59
The goal of Moonshot is thus to use and make all these technologies work together as in the following 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
Page 18 of 59
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:
Page 19 of 59
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
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
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
"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
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
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" } }
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
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).
Page 26 of 59
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
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
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
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:
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
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.
@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
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.
Page 32 of 59
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
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
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
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
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
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
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 } } } } }
Page 39 of 59
"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
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
Page 42 of 59
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.
Page 43 of 59
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.
Page 44 of 59
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).
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
Page 47 of 59
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.
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
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.
Page 49 of 59
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.
Page 50 of 59
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.
2.
4.
Page 51 of 59
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
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].
Page 53 of 59
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.
Page 54 of 59
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
[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
[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
[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
Figure 15: Conceptual schema of the OpenStack Grizzly architecture - Source Solinea.com
Page 59 of 59