Degree project in [611922]

Licență

Degree project in [611922]

Byadmin ianuarie 1, 2024

Degree project in
Communication Systems
Second level, 30.0 HEC
Stockholm, SwedenRASIB HASSAN KHAN Integration of OpenID Decentralized Authentication in
OpenStack Nova
KTH Information and
Communication Technology

AALTO UNIVERSITY
School of Science and Technology
Faculty of Information and Natural Sciences
Department of Computer Science and Engineering
Rasib Hassan Khan
Decentralized Authentication in
OpenStack Nova
Integration of OpenID
Master’s Thesis
Espoo, June 2011
Supervisors: Professor Tuomas Aura, Aalto University, Fin land
Professor Gerald Maguire Jr., The Royal Institute of Techno logy, Sweden
Instructor: Jukka Ylitalo D.Sc. (Tech.), Nomadic Lab, Eric sson Research, Finland

AALTO UNIVERSITY ABSTRACT OF
School of Science and Technology MASTER’S THESIS
Faculty of Information and Natural Sciences
Degree Programme of Security and Mobile Computing
Author: Rasib Hassan Khan
Title of Thesis:
Decentralized Authentication in OpenStack Nova
Integration of OpenID
Date: June 2011 Pages: 11 + 88
Professorship: Data Communications Software Code: T-110
Supervisors: Professor Tuomas Aura
Professor Gerald Maguire Jr.
Instructor: Jukka Ylitalo D.Sc. (Tech.)
The evolution of cloud computing is driving the next generat ion of
internet services. OpenStack is one of the largest open-sou rce cloud
computing middleware development communities. Currently , OpenStack
supports platform speciﬁc signatures and tokens for user au thentication.
In this thesis, we aim to introduce a platform independent, ﬂ exible,
and decentralized authentication mechanism in OpenStack. We selected
OpenID as an open-source authentication platform. It allow s a
decentralized framework for user authentication. OpenID h as its own
advantages for web services, which include improvements in usability and
seamless SSO experience for the users.
This thesis presents the OpenID-Authentication-as-a-Ser vice APIs in
OpenStack for front-end GUI servers, and performs the authe ntication
in the back-end at a single Policy Decision Point. The design was
implemented in OpenStack, allowing users to use their OpenI D Identiﬁers
from standard OpenID providers and log into the Dashboard/D jango-
Nova graphical interface of OpenStack.
Keywords: Authentication, EC2API, OpenID, OpenStack Nova,
OSAPI, Security
Language: English
ii

AALTO-UNIVERSITETET SAMMANFATTNING AV
Tekniska Högskolan DIPLOMARBETE
Fakulteten för Informations och Naturvetenskaper
Utbildningsprogrammet för Datateknik
Auktor: Rasib Hassan Khan
Avhandlingens Titel:
Decentralized Authentication in OpenStack Nova
Integration of OpenID
Datum: Juni 2011 Sidantal: 11 + 88
Professur: Datakommunikationsprogram Kod: T-110
Utvecklingen av molndatabearbetning är drivande nästa gen eration av
Internet-tjänster. OpenStack är en av de största öppen käll kod mellan-
programvara datormoln utveckling samhällen. För närvaran de stöder IT-
plattform speciﬁka signaturer och pollett som för användar autentisering.
I denna avhandling vill vi införa en plattformsoberoende, ﬂ exibel och
decentraliserad autentiseringsmekanism i OpenStack. Vi v alde OpenID
som en öppen källkod autentisering plattform. Det möjliggö r en
decentraliserad ram för användarautentisering. OpenID ha r sina fördelar
för webbtjänster, som omfattar förbättringar i användbarh et och sömlös
SSO-upplevelse för användarna.
Denna avhandling presenterar de OpenID-Autentisering-as -a-Service
APIer i OpenStack för front-end GUI servrar och utför autent isering
i back-end i ett enda politiskt beslut punkt. Designen genom fördes i
OpenStack, så att användarna kan använda sina OpenID kännet ecken
från standarden OpenID leverantörer och logga in på Dashboa rd / Django-
Nova graﬁskt gränssnitt av OpenStack.
Språk: Engelska
iii

Acknowledgements
I am grateful to everyone who supported me throughout my thes is work. I
would like to specially thank my supervisors, Professor Tuo mas Aura and
Professor Professor Gerald Maguire Jr. for their excellent supervision and
valuable feedback throughout the work.
I would like to show special gratitude to my instructor Jukka Ylitalo from
Nomadic Lab, Ericsson Research, Finland, for his constant s upervision and
valuable feedback during the thesis period. I would like to t hank all my co-
workers at Nomadic Lab, and specially Abu Shohel Ahmed for hi s constant
support during the work.
I would also like to thank my colleagues from the NordSecMob p rogram
and the program coordinators for their support during the wh ole Master’s
study period. I am grateful to Prof. Antti Ylä-Jääski from Aa lto
University, director of NordSecMob programme, for his cont inual support
and motivation.
Finally, I thank my parents for their uninterrupted aﬀectio n and moral
support throughout the period of my study, and all through my life. I would
like to thank my special one, friends, family members, and ev eryone else who
supported and inspired me during my whole life.
Espoo, June 2011
Rasib Hassan Khan
iv

Contents
Abstract ii
Sammanfattning iii
Abbreviationsand Acronyms ix
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Area . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Goals and Contributions . . . . . . . . . . . . . . 3
1.4 Organisation of Thesis . . . . . . . . . . . . . . . . . . . . . 4
2 CloudComputingPlatforms 5
2.1 Introduction toCloud Computing . . . . . . . . . . . . . . . 5
2.2 Selection of ACloud Platform . . . . . . . . . . . . . . . . . 6
2.3 OpenStack Nova: The Selected Platform . . . . . . . . . . 8
2.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Authentication and Authorization Framework . . . . 10
2.3.2.1 User Credentials . . . . . . . . . . . . . . . 10
2.3.2.2 RoleBased Access Control (RBAC) . . . . 11
2.3.2.3 The Nova-Manage Module . . . . . . . . . 13
2.3.3 Application Programming Interfaces . . . . . . . . . 14
2.3.3.1 Representational State Transfer (REST) . . 15
2.3.3.2 EC2APIs . . . . . . . . . . . . . . . . . . . 16
v

2.3.3.3 OpenStack APIs . . . . . . . . . . . . . . . 20
2.3.4 Web Interface- Dashboard/Django-Nova . . . . . . 23
2.4 Other Open Source Cloud Middlewares . . . . . . . . . . . 24
2.4.1Cloud.com CloudStack . . . . . . . . . . . . . . . . 24
2.4.2 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . 26
3 OpenIDBackground 28
3.1 OpenID Terminology . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Security in OpenID . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Other Authentication Frameworks . . . . . . . . . . . . . . . 33
4 OpenIDwithOpenStack Nova 35
4.1 OpenID in OpenStack . . . . . . . . . . . . . . . . . . . . . 35
4.2 Applicability of OpenID inOpenStack . . . . . . . . . . . . . 36
4.3 OpenID as aService . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Service Design Concept . . . . . . . . . . . . . . . . 37
4.3.2 OpenID Authentication Service API . . . . . . . . . 38
4.4 Usability of OpenID inOpenStack . . . . . . . . . . . . . . 41
5 Goalsand PrototypeImplementation 43
5.1 Research Methodology . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Dual PDPtoSingle PDP. . . . . . . . . . . . . . . . 43
5.1.2 OpenID Relay Point Complication . . . . . . . . . . 44
5.1.3 Implementating aRESTful Service . . . . . . . . . . 44
5.1.4 Architectural Consideration . . . . . . . . . . . . . . 45
5.2 OpenID Authentication As A Service . . . . . . . . . . . . . 45
5.2.1 Prototype Architecture . . . . . . . . . . . . . . . . . 45
5.2.2 Modiﬁcations in API Server . . . . . . . . . . . . . . 47
5.2.3 Modiﬁcations in Cloud Controller . . . . . . . . . . . 48
5.2.4 Addition of Nova-OpenIDController . . . . . . . . . 49
vi

5.2.5 Modiﬁcations in Auth Manager . . . . . . . . . . . . 50
5.2.6 Modiﬁcations in Nova-Manage . . . . . . . . . . . . 50
5.2.7 Conﬁguration Presets . . . . . . . . . . . . . . . . . 51
5.2.8 Message Sequence . . . . . . . . . . . . . . . . . . 51
5.2.9 Prototype Action Flow . . . . . . . . . . . . . . . . . 53
5.3 OpenID Authentication APIs . . . . . . . . . . . . . . . . . . 56
5.3.1 OpenidAuthReq API . . . . . . . . . . . . . . . . . . 56
5.3.1.1 API Invoke . . . . . . . . . . . . . . . . . . 56
5.3.1.2 Response Format . . . . . . . . . . . . . . 56
5.3.2 OpenidAuthVerify API . . . . . . . . . . . . . . . . . 58
5.3.2.1 API Invoke . . . . . . . . . . . . . . . . . . 58
5.3.2.2 Response Format . . . . . . . . . . . . . . 58
5.4 Dashboard/Django-Nova withOpenID . . . . . . . . . . . . 58
6 Analysisand Discussion 61
6.1 Critical Security Points . . . . . . . . . . . . . . . . . . . . . 61
6.2 UseCaseStudy . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.1 Standard OpenID Providers . . . . . . . . . . . . . . 63
6.2.2 GBAProvider . . . . . . . . . . . . . . . . . . . . . . 63
6.2.3 Performance Evaluation . . . . . . . . . . . . . . . . 64
6.3 Version Information . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7 Conclusionsand FutureWork 69
Bibliography 72
A Executing OpenIDinOpenStack 78
A.1 Setup Information . . . . . . . . . . . . . . . . . . . . . . . 78
A.2 Execution Trace. . . . . . . . . . . . . . . . . . . . . . . . . 79
B Applicabilityof OAuthinOpenStack 84
vii

B.1 OAuth Overview . . . . . . . . . . . . . . . . . . . . . . . . 84
B.2 UseCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.2.1 UseCase1 . . . . . . . . . . . . . . . . . . . . . . . 85
B.2.2 UseCase2 . . . . . . . . . . . . . . . . . . . . . . . 86
B.3 Signalling Sequence Overview . . . . . . . . . . . . . . . . 86
B.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
viii

Abbreviations and Acronyms
3GPP 3rd Generation Partnership Project
API Application Programming Interface
D-H Diﬃe-Hellman Key Exchange
EC2API Elastic Compute Cloud Application Programming
Interface
GBA Generic Bootstrapping Architecture
GUI Graphical User Interface
HTTP Hyper-Text Transfer Protocol
HTTPS Hyper-Text Transfer Protocol Secured
IaaS Infrastructure as a Service
JSON JavaScript Object Notation
MITM Man-in-the-Middle
OP OpenID Provider
OSAPI OpenStack Application Programming Interface
PaaS Platform as a Service
PAP Policy Administration Point
PEP Policy Enforcement Point
PDP Policy Decision Point
RBAC Role Based Access Control
REST Representational State Transfer
RP Relaying Party
SaaS Software as a Service
SAML Security Assertion Markup Language
SHA Secure Hash Algorithm
SOAP Simple Object Access Protocol
SSL Secure Socket Layer
SSO Single-Sign-On
VM Virtual Machine
ix

List of Tables
2.1 User Credentials in OpenStack . . . . . . . . . . . . . . . . . . 11
2.2 RBAC Model in OpenStack Nova . . . . . . . . . . . . . . . . 13
2.3 Commands Categories in Nova-Manage . . . . . . . . . . . . . 14
2.4 Query Parameters for the EC2API in OpenStack . . . . . . . 17
2.5 SHA-1 and SHA-256 Comparison . . . . . . . . . . . . . . . . 19
2.6 XML/JSON Serialization Speciﬁcation in OSAPIs . . . . . . . 22
3.1 Comparison of Authentication Frameworks . . . . . . . . . . . 3 4
4.1 Entities in OpenID Authentication for OpenStack . . . . . . . 40
5.1 Format for OpenidAuthReq EC2API . . . . . . . . . . . . . . 56
5.2 Success Response Format for OpenidAuthReq EC2API . . . . 5 7
5.3 Failure Response Format for OpenidAuthReq EC2API . . . . 5 7
5.4 Format for OpenidAuthVerify EC2API . . . . . . . . . . . . . 58
5.5 Success Response Format for OpenidAuthVerify EC2API . . . 59
5.6 Failure Response Format for OpenidAuthVerify EC2API . . . 59
6.1 Standard OpenID Providers . . . . . . . . . . . . . . . . . . . 63
A.1 Dashboard HTTP 302 Redirection Form . . . . . . . . . . . . 81
x

List of Figures
2.1 Service Oriented Architecture in Cloud Computing . . . . . . 6
2.2 OpenStack Nova Architecture . . . . . . . . . . . . . . . . . . 9
2.3 Role Based Access Control Architecture . . . . . . . . . . . . 11
2.4 A RESTful Client-Server Interaction Example . . . . . . . . . 15
2.5 DashBoard/Django-Nova with OpenStack . . . . . . . . . . . 24
2.6 Cloudstack Architecture . . . . . . . . . . . . . . . . . . . . . 25
2.7 Eucalyptus Architecture . . . . . . . . . . . . . . . . . . . . . 27
3.1 Signalling Sequence for Stateless OpenID Authenticati on . . . 30
4.1 Improper Authentication Enforcement Point . . . . . . . . . . 36
4.2 OpenID-OpenStack Authentication Overview . . . . . . . . . . 37
4.3 Message Sequence for OpenID Authentication API . . . . . . 3 9
5.1 Additions to OpenStack Architecture . . . . . . . . . . . . . . 46
5.2 Signalling Sequence for OpenID Authentication in OpenS tack 52
5.3 Action Flow for OpenID Authentication in OpenStack . . . . 53
6.1 Time Measurements for OpenID Authentication . . . . . . . . 6 5
6.2 Time Measurements for Nova-OpenID Controller . . . . . . . 6 7
B.1 OAuth Use Case Overview . . . . . . . . . . . . . . . . . . . . 85
B.2 OAuth in OpenStack Signalling Sequence . . . . . . . . . . . . 87
xi

Chapter 1
Introduction
Cloud Computing is a new paradigm for utilization of scalabl e resources
over the internet. The Pay-Per-Use model for cloud infra-st ructures has
introduced wide interest among users to utilize such servic es. Major cloud
service providers such as Amazon AWS, Rackspace, Salesforc e, etc. have
driven development of multiple cloud platforms. The most pr ominent among
the open source cloud projects are OpenStack, CloudStack, E ucalytus, and
OpenNebula. The open-source cloud platforms provide the ab ility to deploy
private Infrastructure-as-a-Service (IaaS) clouds. Many open-source cloud
platforms have compatible application programming interf aces (API) with
public clouds such as Amazon AWS, which improves the ﬂexibil ity and
usability of the private clouds. An explanation of the diﬀer ent types of cloud
based services can be found in section 2.1 starting on page 5.
1.1 Motivation
As the open source cloud platforms become increasingly popu lar, usability
is being improved with easy to use web interfaces and cloud se rvice APIs.
Users can use diﬀerent client programs or APIs for accessing the diﬀerent
services on the cloud platform. The graphical user interfac e (GUI) for the
platforms, accessible over the network or the Internet, als o provide support
to access the cloud services in an easy and user-friendly way . Logging into
the cloud managerial console gives the users an easy-to-use dashboard, from
which they can easily view and manipulate their resources. T he management
console is a major requirement for administrators, as it giv es ﬂexibility and
improves usability for managing the users in the system, the ir privileges, the
1

CHAPTER 1. INTRODUCTION 2
resources, and over all control of the cloud deployment.
However, these access mechanisms are still being implement ed by simple web
services. Thus the security threshold is rather low for clou d services. Even
though a lot of research remains focussed on intra-cloud net work security,
data isolation, and policy enforcement; little research ha s been conducted
in the area of security of access points to the cloud platform s. Present
authentication techniques only involve processing reques ts for resources, with
plaintext query/response methods to the local database.
1.2 Problem Area
Web GUI has become the most widely deployed front-end for del ivering
cloud services, both to administrators and users. However, there are certain
limitations in what these fronts-ends make available. In th e context of
authentication of users, there exists the following limita tions:
•The primary concern arises, when the architecture for these web GUI
front-ends are designed using the same structure as traditi onal web
servers. These front-ends were initially intended to simpl ify interaction
of users and administrators with the cloud platform back-en d. This
meant, that unlike traditional web servers, these front end s should be
’dumb’ servers, i.e. , they are only a window to view the avail able
services. However, this is not what the current trend of deve lopment
has done, where at present, they are being implemented as reg ular web
servers providing internet services (see section 2.3.4 on p age 23).
•The users are required to use username/password based login into the
dashboard. This imposes all the disadvantages of such login systems,
including limited usability by users, as compared to authen tication
frameworks such as OpenID [13, 54], Shibboleth [34], SAML [5 1, 57],
etc.
•As the front-end GUI becomes a separate entity, it becomes a
requirement for the front-ends to maintain separate user cr edentials.
This requirement arises from the general concept of web serv ices, where
there is an absence of a federated login architecture. The ab sence
of a centralized authentication architecture gives rise to the problem
mentioned in the next point, of having multiple Policy Decis ion Points
(PDPs).

CHAPTER 1. INTRODUCTION 3
•As the users log into the web GUI, the web front-end uses API
calls to the cloud platform back-end to execute diﬀerent ope rations
on the cloud. This means, the users are ﬁrst authenticated at the
web GUI, and the back-end cloud platform does not play a role i n
the authentication process. This introduces multiple PDPs . This is
contradictory to general security principles, where it is r ecommended
that there should always be a single point of policy decision , while there
can be multiple Policy Enforcement Points (PEPs).
•For the above mentioned reasons, we see that there should be c omplete
trust between front-end GUI and back-end cloud platform. Th is also
means that the front-end GUI can not simply be a "dumb" web ser ver,
but has to be more tightly coupled to the back-end.
1.3 Research Goals and Contributions
The initial part of this research included studying multipl e cloud platforms.
The selection of a suitable cloud platform for developing a p rototype was
an important step, from the perspective of its architecture , future research
scopes, and for further service enhancements. In our resear ch, we worked
with OpenStack (see section 2.3 on page 8) for developing the prototype as
a proof-of-concept.
The research focussed to introduce a decentralized authent ication platform
in OpenStack. Thus, we designed and implemented a mechanism to perform
OpenID based authentication in OpenStack. However, the tar get was to keep
the front-end GUI as a "dumb" server. Hence, we implemented t he OpenID
authentication in the back-end of the OpenStack server, wit h a mechanism to
use OpenID as a service with the help of APIs from the front-en d. The work
included development of a pair of new APIs in the OpenStack AP I server.
Furthermore, an additional module, the Nova-OpenID-Contr oller, was incor-
porated in OpenStack. The implementation followed the curr ent modular
architecture of OpenStack, allowing a distributed OpenSta ck back-end just
like all other existing modules.
Additionally, the prototype implementation included exte nsion of the Django-
Nova and Dashboard (see section 2.3.4 on page 23) GUI. The API s were used
from the web interface, to allow authentication of a standar d OpenID user
and to allow such a user to log into the OpenStack management c onsole.

CHAPTER 1. INTRODUCTION 4
1.4 Organisation of Thesis
The rest of the thesis is organised as follows. Chapter 2 disc usses the
studies on the various cloud platforms, including the archi tectural and
functional details of OpenStack, the selected platform. Th e working
principles of OpenID authentication is explained in chapte r 3. In chapter 4,
we have presented the design for using OpenID-Authenticati on-as-a-Service
in OpenStack. The implemented prototype, its architecture and working
mechanism has been included in chapter 5. Chapter 6 discusse s some
analytical perspectives and evaluations on the developed p rototype. Finally,
chapter 7 provides the summary of the thesis and scopes for fu ture work.
Appendix A includes the traces from executing the OpenStack prototype
implementation. An applicability analysis and initial des ign for OAuth in
OpenStack is included in appendix B.

Chapter 2
Cloud Computing Platforms
2.1 Introduction to Cloud Computing
There are multiple ways to deﬁne Cloud Computing [21]. Ian Fo steret al.
in [38] have deﬁned it as:
"A large-scale distributed computing paradigm that is driv en by
economies of scale, in which a pool of abstracted, virtualiz ed,
dynamically-scalable, managed computing power, storage, plat-
forms, and services are delivered on demand to external cust omers
over the Internet."
Cloud Computing is a relatively new cyber-infrastructure, implying a service
oriented architecture (SOA) for computing resources. User s access cloud
services over a simple front-end interface to utilize the vi rtualized resources.
The SOA in clouds is usually deﬁned in a hierarchical structu re, as shown in
ﬁgure 2.1. The layers of cloud computing services in SOA can b e described
as:
1.Infrastructure as a Service (IaaS) provides virtual CPUs, storage
facilities, memory, etc. according to user requests. IaaS p roviders split,
assign, and dynamically resize the resources ﬂexibly to bui ld ad hoc
systems as requested by clients. Users access the virtualiz ed resources
over the network according to their requirements. Example: Amazon
AWS [3].
2.Platform as a Service (PaaS) acts as an abstraction between the
physical resources and the service. PaaS providers supply a software
5

CHAPTER 2. CLOUD COMPUTING PLATFORMS 6
platform and the application programming interfaces (APIs ), where
users execute their software components. Applications can then be
deployed on the platform, together with other services such as cloud
storage facilities, without the concern for resource avail ability, and
easily scaling up with increasing utilization of the hosted applications.
Example: Google App Engine [6].
3.Software as a Service (SaaS) provide end users with integrated
services from the providers, comprising of hardware, devel opment
platforms, and applications. SaaS is a packaged solution an d is
deployed centrally by the SaaS provider who provides remote access
to its users. The users simply utilize the services over a web interface
and have minimum visibility of the implementation of the ser vice as
compared to IaaS and PaaS. Example: Salesforce.com [18].
Platform As A Service
(PaaS)
Infrastructure As A Service
(IaaS)Software As A Service
(SaaS)
Service Abstraction Resource Visibility
Figure 2.1: Service Oriented Architecture in Cloud Computi ng
2.2 Selection of A Cloud Platform
Currently, there are multiple cloud platform projects bein g developed in the
open source community. All of them aim to fulﬁl the requireme nts of an
IaaS provider. They enable the deployment and management, a long with

CHAPTER 2. CLOUD COMPUTING PLATFORMS 7
the conﬁguration of a multi-subscriber tiered infrastruct ure of cloud services
by enterprises and service providers. However, we will not f ocus on any
of the commercially deployed cloud services, but rather on t he open-source
platforms available for private cloud deployments.
IaaS cloud platforms provide computing resources: CPU, mem ory, disk space,
and network bandwidth. The middleware application uses an h ypervisor
running in the back-end to allow the creation of virtual mach ines (VMs).
These VMs emulate physical computers, and each have a CPU, me mory,
disk, and network resources. The actual physical resources for the creation of
the VMs are provided by virtual hosts. The most popular hyper visors in the
community are KVM, Xen, VMware, VirtualBox, etc. In the impl ementation
of these middleware platforms, libvirt [8] is the most common C/C++ library
used to communicate with the hypervisor from the middleware layer.
All middleware platforms are comprised of multiple modules , which can be
executed in an array of physical resources. When conﬁgured i n a distributed
environment, they provide a collective service for utilizi ng virtual resources
through the cloud middleware. We explored the deployment an d services
for the following mainstream cloud middleware platforms: C loudStack,
OpenStack, and Eucalyptus.
We studied the diﬀerent middleware, from the perspective of their scope for
the integration of an open source decentralized authentica tion mechanism.
Our study primarily focussed on the following features of th e speciﬁc cloud
middleware platforms.
•The architectural modularity of the middleware : This was a
signiﬁcant issue given the objective of our research. Even t hough all
middleware were designed to be deployed in a distributed env ironment,
our concern was the modularity on the diﬀerent operational u nits in
the cloud and the means of communication between the modules .
•The authentication framework : The authentication module re-
quired to be a separate module in the architecture. Addition ally, we
studied the mechanism which was being used to authenticate a request
from a user.
•Detachment of the core resource controller module from the
authentication process : We focussed on a detached core module
from the authentication module. This enabled us to handle th e
authentication process separately, without being concern ed with how
the actual resources are allocated and distributed.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 8
•Provision for API services : We investigated the handling of the
API servers on the middleware, and how requests were passed t o the
core controller. This was an important factor for us to consi der, as
is explained in chapter 4, when we describe the process of dev eloping
OpenID-Authentication-as-a-Service APIs for our selected platform.
•Separation of front-end GUI services from the back-end clou d
servers : With the evolution of web services, it should be noted that
the traditional architecture of web based services is not th e same as
that of cloud services. In cloud servers, as the actual physi cal resources
lie on the back-end, the PDP needs to reside in the back-end, w hich
is not always the case with standard web services. For this re ason, we
required a certain level of detachment and an absence of depe ndency
of the front-end GUI server from the cloud server running on t he back-
end.
•Applicability of OpenID : OpenID is a widely used open platform for
decentralized authentication. We considered the applicat ion of OpenID
authentication where there was a separation of the front-en d GUI from
the back-end.
•Public network exposure of the cloud middleware : Decentral-
ized authentication using OpenID [13] required an exposure to the
public Internet, for interaction with the identity provide rs. Thus, for
security, the speciﬁc module responsible for OpenID authen tication,
should be separated from the core and interacting with the pu blic
Internet.
2.3 OpenStack Nova: The Selected Platform
We considered the above mentioned criteria for the selectio n of a suitable
cloud computing platform, and selected OpenStack for our re search. This
section presents the design and working principles of OpenS tack.
2.3.1 Architecture
Nova, the cloud computing middleware fabric controller fro m OpenStack, is
a widely utilized open source project with many contributor s. It originated
as a project at NASA Ames Research Laboratory and started as o pen-source
software in early 2010.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 9
Public Clients Admin Client
API Server
Cloud Controller Auth Manager Object Store
Volume Controller Network Controller Scheduler Compute ControllerNova-Manage Euca2ools Nova Api Client
OpenStack
APIEC2
APIMethod Call
Method CallREST
Method Call
HTTP
AMQP
Compute ControllerCompute ControllerXML/JSON
Figure 2.2: OpenStack Nova Architecture
OpenStack supports virtualization with KVM, UML, XEN, and H yperV,
using the QEMU emulator. The central core of OpenStack Nova i s the Cloud
Controller, which interacts with the other modules in diﬀer ent ways. As
shown in ﬁgure 2.2, the following are the components of OpenS tack:
•Cloud Controller is the central component which represents the
global state, and interacts with the other components.
•API Server is an HTTP server which provides two sets of APIs to
interact with the Cloud Controller: the Amazon EC2APIs and t he
OpenStack OSAPIs.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 10
•Auth Manager provides authentication and authorization services for
OpenStack, which can interact with the Nova-Manage client u sing local
method calls.
•Compute Controller provides the compute server resources.
•Scheduler is responsible for selecting the most suitable Compute
Controller to host an instance.
•Object Store component is responsible for storage services.
•Volume Controller provides permanent block-level storage for the
compute servers.
•Network Controller handles the virtual networks for the VMs to
interact with the public network.
2.3.2 Authentication and Authorization Framework
The authentication of requests from a user, and the authoriz ing of resources
for the request are handled by the Auth Base module. OpenStack uses a
Role Based Access Control (RBAC) [58] mechanism to enforce policies. For
administrative operations, the Nova-Manage module is used to interact with
theAuth Base database (as shown in ﬁgure 2.2). The following sub-section s
discuss the credentials maintained for each OpenStack user , followed by a
description of OpenStack’s RBAC model, and details of the Nova-Manage
module.
2.3.2.1 User Credentials
When a user is created, an Access Key and a Secret Key are assigned to
the user. They can be randomly generated or can be speciﬁed by the
administrator during user creation. The credentials in the user database
for each OpenStack user are shown in table 2.1.
These credentials are used in diﬀerent ways to authenticate a user’s incoming
API requests. The use of these credentials will be discussed in section 2.3.3
on page 14. The use of the access key and the secret key diﬀer fr om their use
in EC2APIs (see section 2.3.3.2 on page 16) and OSAPIs (see se ction 2.3.3.3
on page 20). This diﬀerence is due to a design inconsistency i n the core of
OpenStack, and is currently under consideration for modiﬁc ation.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 11
Table 2.1: User Credentials in OpenStack
Credential Description
id Unique identiﬁer for each user
name Usually, human readable username for a user
access_key Unique, and can be randomly generated or speciﬁed during use r
creation
secret_key Unique, and can be randomly generated or speciﬁed during use r
creation
is_admin Set to "1" if an "admin" user is created, or "0" otherwise
2.3.2.2 Role Based Access Control (RBAC)
OpenStack uses a Role Based Access Control (RBAC) [58] mecha nism to
enforce authorization of resources within the cloud. In RBA C, instead
of deﬁning speciﬁc privileges for each user, the platform de ﬁnes a set of
permissions based on the user’s authorization. Each set of p ermissions is
referred to as a "role" or a "security group", and each user is associated with
a speciﬁc role. Thus, the role deﬁnes the authorized actions when a user
attempts to access a service, as shown in ﬁgure 2.3.
Figure 2.3: Role Based Access Control Architecture

CHAPTER 2. CLOUD COMPUTING PLATFORMS 12
In OpenStack Nova, the administrators are only allowed to de ﬁne the set of
rules for each role, and assign a role to the users. This great ly simpliﬁes the
task of management of users and organizational security.
OpenStack Nova deﬁnes ﬁve diﬀerent roles for the users, whic h the admin-
istrator has to assign to each OpenStack user. Roles in OpenS tack can be
global or project speciﬁc. The following are the roles used i n managing users
in OpenStack:
1.Cloud Administrator (admin) : Users assigned this role have
complete system access and modiﬁcation privileges. Users c an be
created with admin roles for speciﬁc projects, and will have all the
same rights as an administrator. The administrators are all owed to
add, remove and modify users, projects, keys, images, and in stances.
They are also allowed to manage the access network, and modif y roles
for other users.
2.IT Security (itsec) : This is a global role, and is limited to IT security
personnel. Users of this role are allowed to quarantine inst ances.
However, this is not one of the commonly used roles in OpenSta ck
deployments.
3.Project Manager (projectmanager) : Project owners are assigned
this role by default. A project manager is allowed multiple o perations,
and could alternatively be termed as the administrator for t he speciﬁc
project. Thus, project managers are allowed to perform just the same
operations as administrators, but only on the speciﬁc proje ct.
4.Network Administrator (netadmin) : This role allows users to
perform speciﬁc network related actions on OpenStack. Thus , a
netadmin is allowed to allocate and assign the IP addresses f or the
VMs, and also manage the ﬁrwall policies for the access netwo rk.
5.Developer (developer) : This is the default role assigned to users
created via OpenStack. This is a general purpose role, and th e users
are required to be added to speciﬁc projects. Once added, the users
can create and download access keys, and use the access keys t o access
any running instances within the project. A developer is all owed to
use the operations which are available for all user roles, an d include
viewing instances, images, volumes, keypairs, and additio nally, create
his own keypair to access the instances.
An overview of the roles and their privileges is summarized i n table 2.2

CHAPTER 2. CLOUD COMPUTING PLATFORMS 13
Table 2.2: RBAC Model in OpenStack Nova
Roles admin itsec projectmanager netadmin developer
Global yes yes no no no
Local no no yes yes yes
Key
Managementyes yes yes n/a yes
Instance
Managementyes no yes n/a no
Image
managementyes no yes n/a no
Network
Managementyes no yes yes no
Project
Managementyes no yes n/a no
Create/Modify
Firewallyes no yes yes no
2.3.2.3 The Nova-Manage Module
As shown in ﬁgure 2.2, OpenStack provides the Nova-Manage module for
administrative tasks such as user, roles, vpn, network, and other management
functions. Nova-Manage is a self-executable python comman d-line tool, with
speciﬁc commands to directly interact with the OpenStack da tabase. After
a user is created, the operations of including the user in a sp eciﬁc project,
deﬁning their roles, etc. are all done through the Nova-Manage module.
Each nova-manage command is in the form:
$ nova-manage category command [args]
For example, the list command in the fixed category displays the pool of
all existing ﬁxed IP addresses, and is written as:
$ nova-manage fixed list
The command can also be run without arguments, and it would sh ow the
list of available command categories, that is:
$ nova-manage
A summary of the diﬀerent command categories available with nova-manage
is shown in table 2.3. Additionally, if the command category is run without
any arguments, it displays all the available operations for the speciﬁc

CHAPTER 2. CLOUD COMPUTING PLATFORMS 14
Table 2.3: Commands Categories in Nova-Manage
Category Commands Description
user admin, create, delete, ex-
ports, list, modify, revokeOperations related to OpenStack users
project add, create, delete, environ-
ment, list, modify, quota,
remove, scrub, zipﬁleOperations related to OpenStack projects
role add, has, remove Operations on the OpenStack user roles
shell bpython, ipython, python,
run, scriptProvides a command line prompt for the
supported engines
vpn change, list, run, spawn Operations on virtual private netw orks
(VPNs) between VMs on the cloud
fixed list Displays all the ﬁxed IP addresses available
for the VMs on the cloud
floating create, delete, list Network management options for ﬂoatin g
IP addresses for the VMs on the cloud
network create, list Network management options for available
networks for the IP pool for created VMs
service disable, enable, list Operations on the diﬀerent service mo d-
ules for the OpenStack deployment
log request Generate log ﬁles for speciﬁc service
modules
db sync, version Operations for OpenStack database main-
tenance
volume delete, reattach Operations on the volumes available for th e
VM instances on the cloud
flavor create, delete, list Management of available hardware conﬁ g-
uration for VM instances.
category. For example, the following command displays the o perations
available for "user" :
$ nova-manage user
2.3.3 Application Programming Interfaces
OpenStack Nova exposes two sets of APIs: the OpenStack API (O SAPI)
and Amazon Elastic Compute Cloud API (EC2API). The OSAPI is t he
list of APIs being developed as OpenStack matures with time. On the
other hand, the EC2APIs are a list of comprehensive APIs, des igned and
deﬁned by Amazon Web Services (AWS) [3]. In all cases, OpenSt ack relies

CHAPTER 2. CLOUD COMPUTING PLATFORMS 15
on Representational State Transfer (REST) to handle the res ponses from the
APIs. The following sub-section discusses REST in detail. L ater sub-sections
discuss the two sets of APIs for OpenStack Nova.
2.3.3.1 Representational State Transfer (REST)
REST [37, 55, 42, 43] is an architecture for designing web app lications. In
typical implementations, REST relies on a stateless, clien t-server, cacheable
communications protocol, usually over HTTPS. An example of a RESTful
client-server interaction is shown in ﬁgure 2.4.
ClientServer
ClientService1
Service2 GET http://www.server.com/Service1
<?xml version="1.0" ?>
<Service1Response>
………….
</Service1Response>
GET http://www.server.com/Service2?
Param1=X&Param2=Y
<?xml version="1.0" ?>
<Service2Response>
………….
</Service2Response>
Figure 2.4: A RESTful Client-Server Interaction Example
REST introduces a method for addressing and deﬁning resourc es and enables
us to write web services using a Uniform Resource Identiﬁer ( URI) [26]. All
clients and servers supporting HTTP/HTTPS can use REST reso urces with
the speciﬁc URIs that are implemented by the server.
In REST, the terminology "resources" refers to any API residing on a
RESTful server. The information being sent by the client to t he REST
server can be included in the HTTP headers or in the URI, both o f which
are acceptable by standard REST practices. The response to a REST API
call depends on the service provider, and can range from a sim ple text string
to a fully described XML object.
REST requires the API calls to be sent over HTTPS (HTTP runnin g
over SSL) for conﬁdentiality, integrity and authenticity. Thus, for security

CHAPTER 2. CLOUD COMPUTING PLATFORMS 16
reasons, both the client and the server must implement the SS L technology
in RESTful services.
As RESTful services are stateless, each request is required to be handled
in complete isolation. Hence each request should include al l the required
information to invoke the speciﬁc API at the RESTful server. The server
never stores a "state" from previous requests, and the client should resend
parameters if required.
The fundamentals of REST include:
•A resource is described as any information or services, whic h is
accessible by a client from a RESTful server. As shown in ﬁgur e 2.4,
Service1 andService2 can be referred as resources.
•Each resource on a RESTful server is uniquely referenced usi ng a URI.
(e.g. http://www.server.com/Service1 )
•Any interaction with a resource residing on a RESTful server is
stateless.
•Communication and manipulation of resources are done with t he four
generic HTTP methods: GET, POST, PUT and DELETE.
All API services on OpenStack are RESTful. However, even tho ugh REST
requires HTTPS connections for security reasons, current i mplementation of
the API Server on OpenStack does not use HTTPS. Implementati on of the
API server with HTTPS is a future development task for OpenSt ack, but
not yet incorporated in the framework.
2.3.3.2 EC2 APIs
Amazon EC2 has introduced the EC2APIs, which allows users to interact
with Amazon AWS services, along with the server instances in Amazon’s data
centers. The EC2APIs have also been implemented in OpenStac k, similar
to their implementation in Amazon AWS [1]. These APIs suppor t Query
requests, which are basic HTTP requests to the RESTful API Se rver. The
EC2APIs on OpenStack use the HTTP GET method. The data sent as
response to the request are serialized as XML objects. Howev er, OpenStack
currently do not incorporate any security mechanisms, and t he messages are
interchanged over HTTP as plaintext.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 17
The APIs in OpenStack are accessible by sending Query reques ts to the Nova
API server. For using these APIs, the Access Key and the Secret Key are used
as the AWSAccessKeyID andAWSSecretKeyID respectively. By default, the
Nova API Server uses TCP port 8773, and upon invoking a speciﬁ c API, it
uses method calls to interact with the Nova Cloud Controller .
All requests include mandatory ﬁelds [1], including an "Action" parameter,
which is used to specify the requested operation with the API . Another
important parameter to validate the integrity of the reques t is the "Signature"
parameter. The whole HTTP query string is used to generate th e signature
for a request, with the AWSSecretKeyID ( secret_key ) as the key, and the
SHA-256 hash algorithm.
Signature = HashFunction (
HTTP_Verb + "\n" +
Host_Header + "\n" +
HTTP_Request_URI + "\n" +
QueryString
)
Therefore, for making an EC2API call, we ﬁrst generate the si gnature, and
then append it to the arguments in the query string in the REST URI for the
speciﬁc API. It should also be mentioned, that all text in the URL should be
encoded as speciﬁed in RFC 3986 [26]. The common parameters a long with
examples of using them in RESTful EC2API requests are shown i n table 2.4.
Table 2.4: Query Parameters for the EC2API in OpenStack
Parameter Name Example Required
Action Action=DescribeProjects yes
Version Version=nova (DEFAULT) yes
AWSAccessKeyId AWSAccessKeyId=admin (manually speciﬁed)
or AWSAccessKeyId=617367c3-46f2-40ba-8fd7
(randomly generated)yes
Timestamp Timestamp=2011-05-02T08:21:56 yes
Signature Signature=zPtTNga4ftpjxoPzqRot/tFo62aqM= yes
SignatureMethod SignatureMethod=HmacSHA256 yes
SignatureVersion SignatureVersion=2 (DEFAULT) yes
Name Name=rasib no

CHAPTER 2. CLOUD COMPUTING PLATFORMS 18
The diﬀerent parameters and their purpose are as follows:
1.Action : Used to request a speciﬁc action, which is being invoked by
the speciﬁc API.
2.Version : The speciﬁc version of EC2API being invoked. This is
important in the EC2API set in Amazon AWS [3]. In the case of
OpenStack, we use the default value of "nova" .
3.AWSAccessKeyId : The Access Key ID ( Access Key ) for the user
sending the request. They can be automatically generated, o r manually
speciﬁed when creating a user on OpenStack.
4.Timestamp : The date and time at the client, when the speciﬁc API
query call was signed. The timestamp is in the format YYYY-MM –
DDThh:mm:ss. Alternatively, Amazon AWS EC2APIs [1] allows the
"Expire" parameter instead of "Timestamp" .
5.Signature : The signature of the query request using the required
parameters. As mentioned above, this is generated from the q uery
request, and then appended with the query parameters. For au then-
tication, once a request is received, the signature is regen erated, and
compared to the one included in the request.
6.SignatureMethod : The hash algorithm used to create the signature
for the query request. For signing EC2API calls, either SHA- 1 or
SHA-256 hash algorithms can be used for the signature. OpenS tack
implements both SHA-1 and SHA-256 hash algorithm for the sig nature
veriﬁcation in the query requests (similar to AWS EC2APIs [1 ]). Both
SHA-1 and SHA-256 are strong hash algorithms, with SHA-256 b eing
more resistant to collision attacks because of its greater o utput size. A
comparison of both the algorithms is shown in table 2.5.
7.SignatureVersion : The signature version which has been used to sign
the query request. The default value, for both Amazon AWS, an d in
OpenStack is "2".
8.Name: An optional parameter along with the query request, to spec ify
the name of the user. It is usually used when the AWSAccessKeyId
is a random long string, and this parameter speciﬁcally prov ides the
username in human readable text.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 19
Table 2.5: SHA-1 and SHA-256 Comparison
Algorithm Internal
State
Size(bits)Output
Size(bits)Block
Size(bits)Max.
Message
Size(bits)Rounds
SHA-1 160 160 512 264−1 80
SHA-256 256 256 512 264−1 64
The whole query string is used to generate the signature in an EC2API call.
For example, for the DescribeProjects API, the parameters for generating the
signature would look like the following:
Signature = HashFunction (
GET\n
localhost:8773\n
/services/Admin/\n
AWSAccessKeyId=admin
&Action=DescribeProjects
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=2011-03-02T08%3A20%3A38
&User=admin
&Version=nova
)
Thus, with all the standard parameters, the format for a quer y request to the
EC2API server on OpenStack, with a DescribeProjects action request looks
like the following:
GET http://localhost:8773/services/Admin/?AWSAccessK eyId=admin&
Action=DescribeProjects&SignatureMethod=HmacSHA256& SignatureVer
sion=2&Timestamp=2011-03-02T08%3A20%3A38&User=admin &Version=nova&
Signature=YKII5A1hCm2iztjT%2BfcDKee0nSxsjrs%3D HTTP/ 1.0
The EC2API server replies to API calls with XML data serializ ation, with
a speciﬁc structure for each action. For example, for the DescribeProjects
action API call above, OpenStack responds with the followin g XML:

CHAPTER 2. CLOUD COMPUTING PLATFORMS 20
<?xml version="1.0" ?>
<DescribeProjectsResponse xmlns="http://ec2.amazonaw s.com/doc/nova/">
<requestId>P7HBV0KXPVLOC628Y7N</requestId>
<projectSet>
<item>
<projectname>AdminProject</projectname>
<projectManagerId>admin</projectManagerId>
<description>AdminProjectDesc</description>
</item>
</projectSet>
</DescribeProjectsResponse>
2.3.3.3 OpenStack APIs
The OpenStack Compute API (OSAPI) [53] was initially design ed by Rack-
space US [17], the initiators of OpenStack. OSAPI is a RESTfu l web service
interface, and supports both JavaScript Object Notation (J SON) [28] and
XML data serialization.
By default, the OSAPI server runs on TCP port 8774 of the OpenS tack
Server. Each HTTP query request to the OSAPI requires speciﬁ c authen-
tication credentials. It uses the X-Auth-User and the X-Auth-Key header
values in the query requests to specify the username and the API Access Key
respectively. However, similar to EC2APIs, the OSAPIs also communicates
over HTTP with plaintext messages.
For using OSAPIs, the username is the " Name " parameter in the user
database, and this value is placed in the X-Auth-User ﬁeld. Along with
that, the API Access Key , is placed in the X-Auth-Key ﬁeld, and is matched
against the Access Key from the user credentials table in the database. After
an initial authentication request to an Authentication URL , if successful, an
X-Auth-Token is returned by the server.
For authenticating a user to OpenStack with OSAPI, an authen tication
request would have the following format:
GET /v1.0 HTTP/1.1
Host: <OSAPI_Server_Authentication_URL>
X-Auth-User: <username>
X-Auth-Key: <access_key>

CHAPTER 2. CLOUD COMPUTING PLATFORMS 21
Once an authentication request is received, the request is v alidated by
comparing the Access Key and the Name against the X-Auth-Key and the
X-Auth-User respectively. If successful, the X-Auth-Token is generated, by
a hashing the username , the access key , and a timestamp .
Token = HashFunction (
username + access_key + timestamp
)
All of the required information for the token are stored in th e OpenStack
database, and are compared against the hash value of the toke n hash. A
successful authentication responds with an " HTTP 204 No Content " response
with the X-Auth-Token in the header, as shown below:
HTTP/1.1 204 No Content
Date: <Day>, <Date> <Month> <Year> <Time:hh:mm:ss>
Server: Nova
X-Server-Management-Url: <OSAPI_Server_Authenticatio n_URL>
X-Storage-Url: <NULL>
X-CDN-Management-Url: <NULL>
X-Auth-Token: <Token>
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
The X-Server-Management-Url is the URL where all operation requests
should be made for OSAPIs. The X-Storage-Url andX-CDN-Management-
Urlare ﬁelds used by Rackspace [17], but do not currently provid e any
speciﬁc features within OpenStack.
At present, the token issued by OSAPI is considered valid for a duration of
2 days, after which, the client has to perform another authen tication and
receive a new token. An HTTP 401 Unauthorized response is sent by the
API Server if a request is made with an expired token.
Once the OSAPI client receives the token, it can then send act ion requests
to other APIs on the OSAPI server. In an OSAPI call, the reques t format
(JSON or XML) is speciﬁed using the Content-Type header value. The
desired response format from the server can also be speciﬁed in the API
requests, and can be diﬀerent from the request format. The Accept header
value is used to specify the response format. Additionally, the response
format can be referenced using .xml or.json extension in the query request,

CHAPTER 2. CLOUD COMPUTING PLATFORMS 22
which essentially refers to diﬀerent "resources" in the REST request line. A
comparison of XML and JSON type request and response formats is shown
in table 2.6.
Table 2.6: XML/JSON Serialization Speciﬁcation in OSAPIs
Format Content-Type/Accept Header Query Entension Defaul t
JSON application/json .json yes
XML application/xml .xml no
An example API request with a JSON header, but specifying an X ML return
type, for retrieving the list of " ﬂavors " would look like the following:
GET /flavors HTTP/1.1
Host: http://localhost:8774/
Content-Type: application/json
Accept: application/xml
X-Auth-Token: adflkroiabdl-adf-asdadfwr-agfger
The Content-Type parameter can be changed to "application/xml" to
specify an XML request type. Alternatively, the Accept parameter could be
changed to "application/json" to specify a JSON return type. To specify
a return type serialization in the query extension, the ﬁrst line of the request
would look like the following:
GET /flavors .xml HTTP/1.1
Host: http://localhost:8774/
…
Upon successful authentication of the token, an example XML response for
the"ﬂavors" would look like the following:
<?xml version="1.0" encoding="UTF-8"?>
<flavors xmlns="http://localhost:8774/servers/api/v1 .0">
<flavor id="1" name="Medium" ram="1024" disk="20" />
<flavor id="2" name="Large" ram="4012" disk="50" />
</flavors>
If the serialization type for the response was speciﬁed as JS ON, the response

CHAPTER 2. CLOUD COMPUTING PLATFORMS 23
would look like the following:
{
"flavors" : [
{ "id":1, "name":"Medium", "ram":1024, "disk":20 },
{ "id":2, "name":"Large", "ram":4012, "disk":50 }
]
}
2.3.4 Web Interface – Dashboard/Django-Nova
The ongoing work in OpenStack is also focussed towards devel oping an easy-
to-use managerial Web GUI. The GUI is built on the Django fram ework, the
"Django-Nova" project, with another wrapper framework for the interface
called "Dashboard".
The Django-Nova framework is an implementation layer of the APIs for
OpenStack. Currently, the EC2APIs (see section 2.3.3.2 on p age 16)
implemented in OpenStack provide a more comprehensive list of functions.
Thus, Django-Nova uses the EC2APIs to implement the GUI for O penStack.
Dashboard is a wrapper implementation of the Django framewo rk for
OpenStack. It provides the views for the graphical interfac e. As shown in
ﬁgure 2.5, Dashboard simply returns the HTML views for the GU I. Internally,
it uses python method calls to the Django-Nova framework. Su bsequently,
Django-Nova implements the EC2API calls, and thus interact s with the API
server on OpenStack.
Django-Nova uses an "admin" user account on OpenStack back- end, and
requires the access and secret keys for the "admin" user duri ng conﬁguration
of the front-end GUI. It uses these keys to interact with the A PI server,
on behalf of the users accessing the services from OpenStack through the
Dashboard. Initially, the Administrator account is used to retrieve the
speciﬁc user credentials from OpenStack. Once received, Da shboard/Django-
Nova then uses that user’s credentials to further access the resources.
Additionally, the GUI front-end incorporates a separate us er management in
the Django framework. When a user tries to access the manager ial console,
the user ﬁrst authenticates with the Dashboard/Django-Nov a authentication
system. Once authenticated, the user is allowed access to th e managerial
console, and then, the HTML views for the dashboard are proce ssed
according to the responses from the OpenStack API server.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 24
User
EC2 API
Calls
XML
ResponseCloud
Services
Method
Calls
Web Server
User Actions,
Variables,
Commands
HTML
Views
OpenStack Server
Figure 2.5: DashBoard/Django-Nova with OpenStack
As we will see later, the separate management of user authent ication will
be the focus of our research. This separate authentication f ramework is
responsible for the incompatibility with standard securit y practices of having
a single PDP in contrast to multiple PDPs (as used is the curre nt design)
[25, 40].
2.4 Other Open Source Cloud Middlewares
There are numerous cloud platforms being researched and und er construc-
tion. While some remain proprietary, some are open-source. In our study, we
evaluated the open-source cloud middleware solution provi ded by Cloud.com ,
CloudStack [27], and another called Eucalyptus [5, 48]. The following
sections discuss the architectural speciﬁcations of these two platforms.
However, there are other well known open-source IaaS platfo rms, such as
OpenNebula [14], Hadoop [7], etc., which for lack of time hav e not been
included in these discussions.
2.4.1 Cloud.com CloudStack
The CloudStack open-source cloud computing platform is pow ered by
Cloud.com . The community edition is the open-source tool, and has been
in development since 2008. CloudStack oﬀers an innovative o pen-source
software technology for deploying either public or private cloud environments.

CHAPTER 2. CLOUD COMPUTING PLATFORMS 25
CloudStack oﬀers a well deﬁned and easy-to-use AJAX enabled graphical web
interface, with the core mainly coded in Java. Once the admin istrator/user
logs in, the dashboard oﬀers all the expected services, incl uding the creation
of domains, memory allocation, CPU type deﬁnition, creatio n, launching and
termination of virtual machine instances, monitoring the p erformances of the
virtual machines, etc. It is a ready-to-deploy package, wit h a complete set
of functionalities.
The architecture of CloudStack introduces three separate c omponents, and
a four layer approach, as shown in ﬁgure 2.6. The compute cont roller is
the module which manages the VM instances. The compute contr oller uses
a hypervisor to realize the operations. The network control ler manages the
bridges to the hardware interface, along with the virtual lo cal networks for the
VM instances. The storage controller is the module which pro vides storage
facilities, mainly for image management for VM creation, al ong with VM
instance snapshots.
CloudStack Manager GUI
CloudStack API
CloudStack Bussines Logic Layer
CloudStack Orchestration Engine
Compute
ControllerNetwork
ControllerStorage
Controller
GUI User
API User
Figure 2.6: Cloudstack Architecture
The CloudStack API server exposes an interface, which devel opers can use to
make API requests with HTTP calls, and interact with CloudSt ack according
to the deﬁned actions. The API requests are in the form:
http://<apiURL>?command=<apiCommand>&<param1=val>&< param2=val>

CHAPTER 2. CLOUD COMPUTING PLATFORMS 26
CloudStack incorporates two diﬀerent API URLs. The public A PI URL
allows access for developers and users, and access to this UR L must be
secured. The private API URL allows full, unsecured access t o the entire
API server, and is assumed to be secured behind a ﬁrewall. Apa rt from that,
there is also the CloudStack Manager, which is a fully integr ated web service
point, providing a GUI for the users.
Below the interface layer, is the CloudStack business logic layer. This layer
incorporates the functionality for authorization and acco unting operations.
The bottom layer, the Orchestration Engine, directly inter acts and schedules
the operations of the compute controller, the network contr oller, and the
storage controller.
2.4.2 Eucalyptus
Another popular open-source cloud middleware platform is E ucalyptus.
Eucalyptus has been developed at the University of Californ ia, Santa
Barbara. It is believed to be a portable, modular, and simple IaaS
platform for research organizations, and was built to resem ble Amazon AWS.
Additionally, it includes features such as WS-Security pol icies [57] with SOAP
[63] for secure communication between its internal compone nts.
As shown in ﬁgure 2.7, the Eucalyptus architecture is a simpl e hierarchical
structure with node controllers, cluster controllers, and cloud controller.
The user interface mainly relies on Java, while the underlyi ng layer in built
with Python and C. However, Eucalyptus seemed to have slowed down its
development, and is already a matured solution. It is very ea sy to deploy, and
is a relatively integrated product, that does not allow many modiﬁcations of
its architecture.
The entry point to the Eucalyptus platform is through the clo ud controller.
This includes an API engine, which includes both REST and SOA P [63]
protocols to handle the requests, make high level schedulin g operations, and
implement them on the cluster controllers. Handling of both REST and
SOAP requests in the API engine is completely compatible wit h Amazon’s
EC2APIs [1]. Additionally, it includes a web GUI, through wh ich users
and administrators can perform diﬀerent management operat ions in the
cloud. Not shown in the diagram, the cloud controller also in corporates
a storage controller, referred to as Walrus. The storage con troller provides a
mechanism to store and access VM objects and user data, and im plements
Amazon’s S3 interface [2].

CHAPTER 2. CLOUD COMPUTING PLATFORMS 27
Cloud Controller
Cluster
Controller
1
Cluster
Controller
2
Cluster
Controller
nAPI InterfaceEC2
SOAP
RequestEC2
Query
Request
WEB Interface
Figure 2.7: Eucalyptus Architecture
A cloud controller can control multiple cluster controller s. Speciﬁcally, a
cluster controller is responsible for scheduling the speci ﬁc node controllers
in its domain for VM executions. Cluster controllers are als o responsible
for managing the virtual local networks for the instances. A s shown
hierarchically, there can be multiple node controllers in e ach cluster. The
node controllers are the speciﬁc hosts, which provide the re sources for the
IaaS, and control the execution, inspection, and terminati on of the VM
instances.

Chapter 3
OpenID Background
OpenID is one of the most popular open source decentralized i dentity
management solutions for web services. In this chapter, we p rovide a detailed
speciﬁcation of the required information on OpenID [13, 54] .
3.1 OpenID Terminology
There are various entities and terms used in the speciﬁcatio n for OpenID
authentication. Below, we provide the terminologies used i n OpenID.
1.Identiﬁer: An "http" or "https" URI used as the OpenID identity, for
a speciﬁc user, or for an OpenID Provider.
2.User-Agent: An HTTP/1.1 [36] client at the user’s end.
3.Relying Party (RP): A web service point which requires user
authentication of an OpenID Identiﬁer.
4.OpenID Provider (OP): An authentication service provider, allow-
ing users to authenticate against a provided OpenID Identiﬁ er.
5.OP Identiﬁer: An Identiﬁer for an OP.
6.User-Supplied Identiﬁer: An Identiﬁer provided by user. A user
may provide either a personal Identiﬁer or an OP Identiﬁer. I f an OP
Identiﬁer is used, after authentication, the OpenID Provid er returns
the speciﬁc user’s Claimed Identiﬁer.
28

CHAPTER 3. OPENID BACKGROUND 29
7.Claimed Identiﬁer: An Identiﬁer ﬁnally returned to the RP from
the OP, which is linked to a local user identity at the RP.
8.Return To URL: The URL provided by the RP, where the OP would
send the User-Agent back after authentication.
9.Trust Root: The URL against which the OP will authenticate the
user.
10.OP Endpoint URL: The absolute HTTP/HTTPS URL which
performs the user authentication. This is discovered by the RP using
the Yadis Discovery Protocol [19] for the Identiﬁer provide d by the user
.
3.2 Authentication
OpenID is a well known open source authentication mechanism . It provides
decentralized user centric identity management for web ser vices, and allows
seamless Single-Sign-On (SSO) authentication. The curren t version of
OpenID is 2.0 [13, 54]. Previously, OpenID 1.0 only supporte d stateful
authentication. However, OpenID 2.0 supports both statefu l and stateless
OpenID authentication. The sequence of a stateless OpenID a uthentication
is shown in ﬁgure 3.1. The stateless OpenID authentication m echanism works
as follows:
1. The User-Agent ﬁrst requests a page over HTTP from a web ser vice
point, which supports OpenID authentication.
2. The web server returns a page over HTTP to the User-Agent.
3. The user supplies the OpenID Identiﬁer, and the User-Agen t submits
the value to the web server.
4. The web server acts as an RP. It normalizes the Identiﬁer, a nd performs
the discovery process, using the Yadis protocol [19] (XRI Re solution
protocol [61] was used in OpenID 1.0, but is avoided in OpenID 2.0). At
this point, the RP receives the meta-information from the OP , required
for the redirection of the User-Agent to the OP endpoint URL.
5. The RP then sends an HTTP 302 Redirection response to the User-
Agent. The redirection includes several diﬀerent paramete rs, including

CHAPTER 3. OPENID BACKGROUND 30
HTTP User Request
HTTP Response
Supply OpenID
Discover OP Endpoint
Retrive Meta-Info
HTTP 302 Redirection
Redirect to OpenID Provider
Authenticate User
HTTP 302 Redirection
Redirect to Web Server OP Discovery
Diffie-Hellman Key Exch.
Verify OpenID Auth
OpenID : Local User
Login
UserWeb Server (RP) OpenID Provider (OP)
Figure 3.1: Signalling Sequence for Stateless OpenID Authe ntication
the "openid.return_to " URL. The URL contains a nonce value gener-
ated by the RP, for example: http://10.0.0.25:8080/openid/verify
/?janrain_nonce=2011-03-23T07:20:56ZLnMsYN .
6. The User-Agent receives the HTTP 302 Redirection , and is redirected
to the OP server, at the OP endpoint URL.
7. The OP can use any method to authenticate the user (such as
username/password, certiﬁcates, smart-cards, generic bo otstrapping
architecture based device authentication [23], etc). Once authenticated,
the OP returns the User-Agent back to the RP, at the return_to
URL speciﬁed by the RP in the previous phase. The OP passes a
long string in the GETrequest line, in order for the RP to validate
the authentication, also referred to as the assertion URL. A n assertion
URL usually holds the following parameters:

CHAPTER 3. OPENID BACKGROUND 31
/openid/verify/?janrain_nonce=<nonce sent from RP>
&openid.ns=<OpenID version specification at OP>
&openid.mode=<id_res:OpenID response>
&openid.op_endpoint=<OP endpoint URL>
&openid.response_nonce=<nonce from OP>
&openid.return_to=<RP return URL>
&openid.assoc_handle=<D-H key association handle at OP>
&openid.signed=op_endpoint,
claimed_id,
identity,
return_to,
response_nonce,
assoc_handle
&openid.sig=<signature of openid.signed parameter value s>
&openid.identity=<authentication user Identifier>
&openid.claimed_id=<claimed user Identifier>
8. At this point, the RP veriﬁes the signature. It re-calcula tes the
openid.sig from the values of all the parameter names included
inopenid.signed . If veriﬁcation is successful, the RP parses the
openid.op_endpoint , and after discovery of the OP, it sets up a
key association using Diﬃe-Hellman (D-H) key exchange [32] and the
openid.assoc_handle .
9. After the D-H key establishment, the RP veriﬁes the respon se for the
speciﬁc openid.identity with the check_authentication operation
for the following ﬁelds which the RP has received from the OP:
op_endpoint ,claimed_id ,identity ,return_to ,response_nonce .
10. Once the parameters are all successfully veriﬁed, refer red to as the
assertion, the RP links the openid.claimed_id with the identity of a
local user in its own server and allows the user to login to the service
point.
In a "stateful" OpenID authentication, the D-H key exchange [32] occurs in
the initial discovery phase at the RP. The " openid.assoc_handle " is stored
together with the shared key at the RP when the shared key is es tablished.
The User-Agent is then redirected to the OP. After authentic ation at the OP
and when the user is redirected back to the RP, there is no D-H k ey exchange.
Instead, the " openid.assoc_handle " is used to retrieve the stored key from

CHAPTER 3. OPENID BACKGROUND 32
the previous step, and the received parameter values are the n veriﬁed. Thus,
in this process, it is required that the RP is able to maintain a key database.
3.3 Security in OpenID
Even with widespread use, OpenID is not fully secure from att acks. OpenID
2.0 had signiﬁcant improvements over OpenID 1.0 [54]. Howev er, any RP or
OP, implementing OpenID functionality, should consider so me issues. Here,
we summarize the diﬀerent threats that OpenID is vulnerable to, including
the results from the OpenID’s working group speciﬁcations [ 13], A. Lindholm
[46], P. Sovis et al. [59], and M. Oostdijk et al. [60].
1.Eavesdropping and Reusing Assertions : OpenID is vulnerable
to eavesdropping attacks if the nonce value in the assertion URL
is not checked. This implementation ﬂaw at the RP or the OP
would allow an attacker to reuse authentication assertions . However,
using an SSL/TLS [31, 44] tunnel to prevent eavesdropping, o r the
implementation executing a check for nonce reuse in the veri ﬁcation
phase, either would prevent assertion reuse.
2.Wrong Use of SSL/TLS : Even with SSL/TLS tunnels in the
authentication process, there might still be potential for intruder
attacks. In some cases, the user might even have a false impre ssion
of security and be a victim to Cross-Site-Scripting attacks [30], if non-
HTTPS Identiﬁers are used. To avoid such loopholes, the sess ion of the
User-Agent with the RP’s service point should be an HTTPS ses sion.
Additionally, the OP’s op_endpoint URL and the RP’s return_to
URL are required to be secured connections for fully secure t ransaction
with the User-Agent.
3.Man-in-the-Middle Attacks (MITM)
(a)Attribute Exchange Vulnerability : OpenID Attribute Exchange
[12] is an extension to OpenID 2.0, which allows the inclusio n
of additional parameters to interchange information betwe en the
RP and OP. The OpenID assertion URL from the OP to the RP
after authentication contains the openid.signed parameter, the
value of which implies all the diﬀerent parameters which hav e been
included in the signature, openid.sig . However, if the additional
parameters in attribute exchange are not included by the OP

CHAPTER 3. OPENID BACKGROUND 33
in the signature, then they are vulnerable to modiﬁcations b y a
MITM.
(b)Attribute Exchange Parameter Injection : A MITM can append
additional parameters in the assertion URL from the OP to the
RP after authentication using Attribute Exchange paramete rs.
Therefore, to detect MITM information injection, the OP sho uld
include all the attribute exchange parameters in the signat ure,
and the RP should verify each parameter when checking the
openid.sig , and verify that all the parameter names are included
inopenid.signed .
(c)Discovery Tampering : The discovery process includes DNS ad-
dress resolution and retrieving the meta-information from the OP.
Both mechanisms are susceptible to attacks. If the DNS resol ution
is somehow manipulated, the MITM can impersonate a false OP.
Furthermore, if the MITM can breach the session between the R P
and the OP, and tamper with the meta-information, the User-
Agent can be redirected as the adversary wants. Security aga inst
these attacks could be achieved using mutually authenticat ed
certiﬁcates for the information being exchanged between th e RP
and the OP.
(d)Adversary Relay Proxy : The MITM could act as a false RP, and
instead of redirecting the user to the OP, could act as a proxy
for the OP. Thus, the adversary RP would acquire the user’s
credentials.
4.Denial-of-Service Attacks (DoS) : DoS attacks are a signiﬁcant
concern for any web services [39]. DoS attacks can be launche d
by a misbehaving RP, by sending repeated OpenID authenticat ion
requests to an OP. Additionally, a misbehaving User-Agent c an also
send repeated requests to an RP, to start the OpenID authenti cation
process. However, using "stateless" OpenID reduces a lot of the pre-
processing and storage tasks for the RP. This has been consid ered in
our design for integration of OpenID in OpenStack, which is d iscussed
later in chapters 4 and 5.
3.4 Other Authentication Frameworks
There are other authentication platforms similar to OpenID , which provide
similar decentralized authentication mechanisms. Micros oft.NET Passport

CHAPTER 3. OPENID BACKGROUND 34
[50], and its successor Microsoft CardSpace [47] are two ide ntity management
platforms from Microsoft. Shibboleth [56, 34] is an open sou rce federated
identity management speciﬁcation, which uses the Security Assertion Markup
Language (SAML) as an internal speciﬁcation. SAML [57, 51] i s an open
standard for exchanging authentication and authorization data between
security domains using XML. With Shibboleth and SAML, users authenticate
themselves to an identity provider, and then the service pro vider and the
identity provider exchange identity credentials in the bac k-end. A summary
of these mechanisms is shown in table 3.1.
Table 3.1: Comparison of Authentication Frameworks
Authentication
FrameworkTechnology Depen-
dencyApplication Domain
OpenID HTTP, open source Decentralized, user-centric, between
provider and service point with user
interaction.
Microsoft.NET
Passport &
CardSpaceOperating system,
client end certiﬁcates,
licensed technology,
WS-Security [57]Centralized, user-centric, Windows work-
station account, between Microsoft Live
and service point with user interation.
SAML XML, open source [57,
51]Organization centric, between provider
and service point without user interaction.
Shibboleth HTTP, SAML frame-
work, open source [57,
34]Organization centric, between provider
and service point without user interaction.

Chapter 4
OpenID with OpenStack Nova
OpenID allows a decentralized and ﬂexible authentication m echanism for
web services. In this chapter, we present the design to integ rate OpenID
authentication in OpenStack Nova.
4.1 OpenID in OpenStack
OpenStack (see section 2.3 on page 8) performs authenticati on, based on
access and secret keys. Using OpenStack with API tools (euca -tools EC2API
client [4], python-nova OSAPI client [16]), is not much of a c oncern. However,
using APIs to interact with cloud services is not a very conve nient form
of interaction. Thus, the GUI plays a more signiﬁcant role in the services
provided to users. The Dashboard/Django-Nova framework (s ee section 2.3.4
on page 23) provides a suitable GUI for users.
OpenStack encourages the use of its APIs (EC2API or OSAPI) fo r imple-
menting front-end GUI services. The weakness in this implem entation is
that, the users are required to be authenticated in a separat e authentication
framework in the front-end, with a username/password pair. Once authenti-
cated, the front-end GUI server then uses the Admin credenti als to retrieve
the user’s credentials. This way, the backend OpenStack ser ver never plays
a role when the GUI server initially authenticates the user.
Therefore, the current approach for developing a front-end GUI for Open-
Stack does not follow the standard practices for policy enfo rcement and
management [25, 40]. In standard architecture for such fede rated login
mechanisms, the front-end GUI server is a "dumb" server, pro viding only
views to the User-Agent. The Policy Administration Point (P AP) and the
35

CHAPTER 4. OPENID WITH OPENSTACK NOVA 36
Policy Decision Point (PDP) are always required to be a singl e point in any
architecture. However, there could be multiple Policy Enfo rcement Points
(PEPs), where the decision by the PDP are enforced.
In contrast to the standards, in the present formation, if Op enID is
implemented on OpenStack, the relaying point will reside in the front-end
server. As shown in ﬁgure 4.1, the GUI server interacts with t he OP,
authenticates the user, and provides access. This makes the front-end act as
a secondary PDP, in parallel to the user administration in th e back-end.
Figure 4.1: Improper Authentication Enforcement Point
4.2 Applicability of OpenID in OpenStack
To apply OpenID authentication mechanism in OpenStack, we ﬁ rst needed
to consider the architectural perspective. Implementing O penID at the front-
end GUI server, as shown in ﬁgure 4.1, and making it act as a sim ple RP
in the process, was a simple task. However, that was not our ta rget, as we
needed to combine a dual-PDP scenario into a single-silo for mation.
Mechanisms such as OpenID were targeted for basic web servic e architec-
tures. In contrast, cloud services such as OpenStack do not n ecessarily follow
such an organisation. As shown in ﬁgure 4.2, our design aim wa s to shift the
point of authentication, the PDP, to the back-end OpenStack server.
Shifting the PDP and performing the authentication in the ba ck-end
requires the front-end to initiate an authentication reque st. This way, the
authentication decision is made in the back-end within the P AP, the Auth

CHAPTER 4. OPENID WITH OPENSTACK NOVA 37
Figure 4.2: OpenID-OpenStack Authentication Overview
Manager module in OpenStack (see section 2.3.1 on page 8).
Enabling OpenID authentication in OpenStack would allow us ers to log into
OpenStack with OpenID URLs. However, the administrator sho uld link an
OpenID URL to an existing OpenStack user to enable OpenID aut hentication
for the user. This is a standard practice in all web services p roviding OpenID
authentication, where a local user is linked to his speciﬁc O penID URL (see
section 3.2 on page 29).
4.3 OpenID as a Service
Performing OpenID authentication on the back-end would com bine the
decision points into a single PDP. Thus, we propose a design t o implement
OpenID-Authentication-as-a-Service on the back-end. The following sub-
sections present the factors considered in the design, foll owed by the detail
messaging sequence to utilize the OpenID authentication se rvice.
4.3.1 Service Design Concept
While designing an architecture to integrate OpenID with Op enStack, we
converged on a solution based upon OpenID-Authentication- as-a-Service for
OpenStack. We considered the following issues when designi ng the solution:
•The front-end GUI should be a "dumb" server, only processing views.

CHAPTER 4. OPENID WITH OPENSTACK NOVA 38
•There should not be any requirement for the GUI server to main tain
any user credentials for authentication.
•Even though the views on the GUI are based on responses from th e
API server, the front-end should interact with the Auth Manager in
the back-end to provide the initial authentication grant.
•The HTTP User-Agent only interacts with the front-end serve r. The
back-end OpenStack server should not have any direct commun ication
with the User-Agent.
•The process of authentication of a user in the front-end shou ld be
realized as a service from the back-end server.
•All interaction between the front-end and the back-end shou ld be
stateless, as required by the RESTful API server [55, 37, 1, 5 3].
•Ensure that we meet all of the speciﬁcations of OpenID [13, 54 ].
•Simplify implementation requirements at the front-end ser ver.
•Ensure all security requirements for OpenID in all phases of interaction,
as discussed in section 3.3 on page section 32.
•Maintain a modular and distributed structure for the integr ation
points, in order to comply with the current architecture of O penStack.
4.3.2 OpenID Authentication Service API
As mentioned in section 3.2 on page 29, OpenID authenticatio n at an RP
involves two phases: (a) OP endpoint URL discovery and retri eving meta-
information, and (b) Verifying an authentication assertio n URL received
from an OP. Therefore, we divided the OpenID-Authenticatio n-as-a-Service
operation in OpenStack into two phases, each invoked with a s eparate API.
The two APIs which have been deﬁned are:
•OpenIDAuthReq: This API is invoked in the initial phase by the
front-end server. It executes an OpenID authentication req uest, and
performs the ﬁrst phase in the process.
•OpenIDAuthVerify: This API is invoked in the second phase by
the front-end server. It executes the authentication veriﬁ cation for the
OpenID authentication assertion URL received from the OP.

CHAPTER 4. OPENID WITH OPENSTACK NOVA 39
The message sequence for OpenID authentication is shown in ﬁ gure 4.3. The
entities in the mechanism are the User-Agent, the front-end GUI Server, the
back-end OpenStack Server, and the OpenID provider. The fun ctionality of
the entities are described in table 4.1.
Figure 4.3: Message Sequence for OpenID Authentication API
Prior to authentication with OpenID, the administrator is r equired to add
a speciﬁc OpenID User Identiﬁer to an existing OpenStack use r. The
information is addded into the user database in OpenStack, w hich is used
later in the process of authentication. The sequence of oper ations for the
user to authenticate against OpenStack, using an OpenID URL are:
1 The user requests the index page from the GUI server with the HTTP
User-Agent.
2 The GUI server returns the login page.
3 The user enters an OpenID Identiﬁer (either user Identiﬁer , or OP
Identiﬁer).
4 The GUI server invokes the OpenIDAuthReq API on the OpenStack
API server to request an OpenID user authentication.

CHAPTER 4. OPENID WITH OPENSTACK NOVA 40
Table 4.1: Entities in OpenID Authentication for OpenStack
Entities Description
User-Agent An HTTP client application running at the user’s
end.
GUI Server A front-end server, running GUI services for
managerial operations on OpenStack.
OpenStack Server The back-end OpenStack server, which is running
the API services for OpenStack.
OpenID Provider The OP, with which the user has already created an
OpenID account.
5 The API functionality is executed at the OpenStack server. The process
runs the Yadis discovery protocol, and performs the OP endpo int
discovery, and retrieves all the other required meta-infor mation from
the OP to redirect the User-Agent to the OP.
6 The API server uses all the parameters for the redirection a nd generates
the response XML for the OpenIDAuthReq API call.
7 The GUI server receives the XML response and parses the cont ents. It
uses the values in the response to generate an HTTP 302 Redirection
for the User-Agent.
8 (a) The User-Agent receives the HTTP 302 Redirection response from
the GUI server. (b) The User-Agent is redirected to the OP end point
URL.
9 The OpenID provider authenticates the user. Authenticati on mech-
anisms can vary from simple username/password, smart cards , client
side certiﬁcates, device authentication (GBA), etc. Once t he user is
authenticated, the OP generates an authentication asserti on response,
with the required parameters and a signature (see section 3. 2 on page
29).
10 (a) The OP sends back the User-Agent to the GUI server. (b) T he GUI
server receives the User-Agent and triggers the next phase o f action
from the front-end server.
11 The GUI server invokes OpenIDAuthVerify API, the second API in the
authentication process, to request veriﬁcation of the Open ID assertion
URL.

CHAPTER 4. OPENID WITH OPENSTACK NOVA 41
12 There are multiple operations in this phase of the authent ication
process.
a The API functionality is executed at the back-end OpenStac k
server.
b The process veriﬁes the signature in the assertion URL, per forms
discovery of the OP, and establishes a D-H shared key. It uses
the key to securely verify all the parameters in the OpenID
authentication assertion URL.
c Once veriﬁed, Auth Manager retrieves the local OpenStack
user, which has the speciﬁc OpenID user Identiﬁer added to it s
credentials.
13 The API server uses the parameters for the successfully au thenticated
user and generates the response XML for the OpenIDAuthVerify API.
If either the user authentication was not successful, or an O penStack
user with the asserted OpenID Identiﬁer was not found, the AP I server
returns an error code in the response XML.
14 The GUI server receives the XML response, and uses the user
information to provide the login, and the HTML dashboard vie w to
the user.
4.4 Usability of OpenID in OpenStack
A lot of discussions on the usability of OpenID has occurred [ 24, 29, 62, 56,
45]. In summary, the following advantages in authenticatio n of users could
be attained with OpenID in OpenStack:
•OpenID is the most widely used open standard for authenticat ion.
There are many OP providers for the user to choose from. These include
Google [41], Yahoo [20], MyOpenID [10], and LiveJournal [9] .
•It will provide a decentralized user centric authenticatio n delegation
for using OpenStack services. Users will have control over h is or her
own identity management and authentication.
•Usability will improve, as OpenID aims for a single user vers us multiple
service points applicability. Users using OpenID for other web services,
can use the same OpenID to use OpenStack services.

CHAPTER 4. OPENID WITH OPENSTACK NOVA 42
•Users will have a seamless Single-Sign-On (SSO) experience . OPs allow
users to remain signed in with the providers, and store cooki es in the
User-Agent to save login information. Thus, when a user is al ready
signed in at the OP, trying to access the OpenStack Dashboard is a
smooth and simple operation for the user, without requiring any extra
interaction for re-authentication.
•Users will have ﬂexibility in the authentication mechanism , as OPs
allow diﬀerent authentication mechanisms for their users. Most
OpenID providers support username/password, and client ce rtiﬁcate
based authentication for users. Apart from that, Leicher et al. in [45]
describe a trusted computing environment using OpenID, A. S . Ahmed
in [24] presents a 3GPP standard authentication mechanism f or smart
phones, and Watanabe et al. in [62] illustrate a cellular subscriber ID
and OpenID federated authentication architecture. Ericss on Labs also
provides an Identity Management service, which uses GBA [23 , 22, 35]
based device authentication services with OpenID.

Chapter 5
Goals and Prototype
Implementation
In this chapter, we present the description and the details o f our prototype
implementation. As mentioned in the research goals (see sec tion 1.3 on page
3), the prototype is a proof-of-concept of the OpenID-Authe ntication-as-a-
Service, as described in section 4.3 on page 37.
5.1 Research Methodology
This section includes the research work carried out to solve the initial
problems. Apart from the details provided in the previous ch apters, this
section presents some of the speciﬁc implementation orient ed investigations
performed.
5.1.1 Dual PDP to Single PDP
As shown previously in ﬁgure 4.2 on page 37, the initial chall enge was
to devise a method to logically shift the front-end GUI serve r’s role for
conducting the OpenID authentication relaying to the back- end OpenStack
server.
Therefore, the design for a dual-API service for providing O penID authenti-
cation was made. With that, the two phases of OpenID authenti cation can
be performed via API calls on the back-end.
43

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 44
5.1.2 OpenID Relay Point Complication
In traditional OpenID implementations, the RP performs all the operations
for OpenID authentication from the same URL domain. This mea ns, the
URL domain the User-Agent requests, is the same domain which performs
the redirection in the initial OpenID authentication reque st with the OP.
Following authentication at the OP, the User-Agent is redir ected to the same
domain, and is the same point from where veriﬁcation of the au thentication
assertion is performed. However, as we split the OpenID auth entication
process with the APIs, we have two domains: the front-end whi ch interacts
with the User-Agent, and the back-end which performs the res t of the
operations.
Thus, we exploited the regular use of the OpenID parameters, by using
the " return_to " and the " trust_root " parameters in a diﬀerent way, but
maintained the OpenID speciﬁcations [13, 54]. We used them t o specify the
front-end URL in the OpenID authentication setup by the back -end with
the OP in the initial phase. As the User-Agent is only in conta ct with the
front-end server, the OP recognises the service point using thetrust_root
information, and eﬀectively redirects the User-Agent to th ereturn_to URL
at the front-end after authentication is performed at the OP .
5.1.3 Implementating a RESTful Service
The OpenStack API Server implements RESTful services. This means, all
services are stateless, and all required information is sen t with each request
to the server. However, in the regular "stateful" OpenID aut hentication, the
D-H shared key is stored after the ﬁrst phase, and is retrieve d during the
veriﬁcation session.
Therefore, we used the "stateless" OpenID authentication m echanism. This
provided us with two beneﬁts. First, it made the OpenID authe ntication
possible to implement in a RESTful manner, without requirin g store of any
information for a session. Second, it provided a subtle prot ection against
DoS attacks on the framework. As the shared key is set up only i n the ﬁnal
phase, any extra processing in the initial phase after invok ing the ﬁrst API
is avoided.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 45
5.1.4 Architectural Consideration
Integrating OpenID functionality on the back-end server re quired some
modiﬁcations in the architecture. Previously, the only mod ule interacting
with the public network was the API Server . However, with OpenID, it is
necessary for OpenStack to have a point of interaction with t he OP on the
public network. Hence, we wanted this to be a separate module , detached
from the core components, to ensure privacy of the internal n etwork.
Therefore, we introduced a new module in the architecture of OpenStack,
to implement the functionality of OpenID authentication. T his module
interacts with the OP in the public Internet on one interface , and with the
Cloud Controller on another interface. In our prototype, the internal
communication is done with XML over HTTP, thus allowing a mod ular
deployment of OpenStack.
5.2 OpenID Authentication As A Service
The following sub-sections describes the architectural de tails of our prototype
for OpenID authentication in OpenStack. All modules, added features, and
extensions are discussed in the following sub-sections. It also includes the
signalling sequence and the architectural action ﬂow in the prototype.
5.2.1 Prototype Architecture
The basic architecture of OpenStack has been discussed prev iously in section
2.3 on page 8, and was shown in ﬁgure 2.2 on page 9.
In our prototype, we introduced some new modules to meet our r equire-
ments, but followed the structure of OpenStack. The modiﬁed OpenStack
architecture is shown in ﬁgure 5.1.
The Nova OpenID Controller is the new module added to the archi-
tecture. Furthermore, we introduced an extension in the API Server ,
theCloud Controller ,Auth Manager and its Nova-Manage admin
client. We also implemented invocation of the APIs from the Django-
Nova/Dashboard framework to use the OpenID authentication function-
ality.
The OpenStack server runs the following services: Nova-API ,Nova-Objectstore ,
Nova-Compute ,Nova-Network ,Nova-Scheduler ,Nova-Volume , and Nova-

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 46
Figure 5.1: Additions to OpenStack Architecture
Ajax-Console-Proxy . In addition to these services, our prototype runs the
Nova-Openid-Controller service on TCP port 9988 by default.
The circular points in ﬁgure 5.1 shows the points of the imple mented
extensions, along with the position of the Nova OpenID Controller . The
following sections present further details of this impleme ntation.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 47
5.2.2 Modiﬁcations in API Server
Our design included two APIs to perform authentication with OpenID in
OpenStack. OpenStack has two sets of APIs, the EC2APIs, and t he OSAPIs
(see section 2.3.3 on page 14).
However, we chose to implement our prototype as an addition i n the
set of EC2APIs. This was because the speciﬁcations of EC2API s are
more well documented and supported by Amazon AWS. Furthermo re, the
functions supported by EC2APIs are more comprehensive comp ared to
OSAPIs. The Django-Nova/Dashboard framework also uses EC2 APIs to
provide the graphical interface to the users. Hence, we impl emented the
OpenID authentication mechanism with EC2APIs, and used the Django-
Nova/Dashboard framework to realize the new API services.
We designed two APIs to perform OpenID-Authentication-as- a-Service from
the front-end server. The following present the design of th e two APIs.
•OpenidAuthReq
–Action Description: The front-end server initially invokes this API
to request an OpenID authentication from the back-end.
–Parameters: All mandatory parameters for an EC2API call (see
section 2.3.3.2 on page 16). Additional parameters include the user
supplied OpenID Identiﬁer, and the " openid.return_to " URL for
the front-end server. The additional parameters are set as v alues
in the " Name" parameter in the EC2API request, separated by an
"&".
E.g. Name=profile.google.com/rasib&http://localhost:
8000/openid-auth-return
–Internal Execution: TheAPI Server receives the request, parses
the parameters, and executes the API functionality with a me thod
call to the Cloud Controller , and waits for the response
variables.
–Response Handler: When the response variables are received
from the Cloud Controller , it generates the response XML
for the API call. The <OpenidAuthReqResponse> tag holds the
parameters in the response XML object.
•OpenidAuthVerify
–Action Description: The front-end server invokes this API to
request an OpenID authentication veriﬁcation from the back -end,

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 48
after the User-Agent has been redirected to the front-end wi th the
assertion URL from the OP.
–Parameters: All mandatory parameters for an EC2API call (see
section 2.3.3.2 on page 16). Additional parameter includes the
whole assertion URL sent from the OP to the return_to URL
at the front-end server. The additional parameter is set as v alue
in the " Name" parameter in the EC2API request. Format of the
assertion URL in OpenID authentication is shown in section 3 .2
on page 29.
–Internal Execution: Similar to the previous API, the API Server
receives the request, parses the parameters, and executes t he API
functionality with a method call to the Cloud Controller , and
waits for the response variables.
–Response Handler: When the response variables are received
from the Cloud Controller , it generates the response XML for
the API call. The <OpenidAuthVerifyResponse> tag holds the
parameters in the response XML object.
5.2.3 Modiﬁcations in Cloud Controller
TheCloud Controller incorporates function handlers for each API in the
API Server . Once the API Server receives a request, it invokes the
speciﬁc handler in Cloud Controller . Thus, we extended the function of
Cloud Controller by including two additional handlers for the two above
mentioned APIs in the API Server .
The corresponding handlers for the two APIs are openid_auth_req() , and
openid_auth_verify() respectively. Both of these handlers in Cloud
Controller internally communicates with the OpenIDHandler sub-module,
which speciﬁcally interacts with the Nova-OpenID Controller .
TheOpenIDHandler communicates with Nova-OpenID Controller with
GET requests over HTTP. In the present implementation, it is assumed
that this interface is within a secured domain. Thus, no addi tional security
is imposed in the messages. However, to ensure maximum secur ity, it is
suggested that HTTPS is used if the deployment does not have a secured
internal network.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 49
5.2.4 Addition of Nova-OpenID Controller
As shown in ﬁgure 5.1 on page 46, the Nova-OpenID Controller module
is added to the OpenStack architecture. It accepts GET reque sts over HTTP
from the Cloud Controller .
TheNova-OpenID Controller uses two sub-domain URLs for the Nova-
Openid-Controller to receive the OpenidAuthReq and the OpenidAuthVer-
ifyaction requests, implemented in a RESTful way. The descript ion of the
processes are as follows:
•OpenidAuthReq ⇒openid_auth_req()
–Service URL: http://localhost:9988/request/
–Required parameters: openid_identifier andreturn_to URL.
–Action: Runs Yadis discovery protocol [19], and discovers the OP
endpoint URL and its speciﬁcations in the meta-information for
theopenid_identifier . It then uses the return_to URL and
the received information to generate the redirectional par ameters.
–Response Parameters: According to the speciﬁcations of OpenID
authentication [54, 13], the following variables are retur ned to
Cloud Controller to be used for the redirection: op_endpoint_url ,
openid.return_to ,openid.realm ,openid.ns ,openid.mode ,
openid.claimed_id , and openid.identity .
•OpenidAuthVerify ⇒openid_auth_verify()
–Service URL: http://localhost:9988/verify/
–Required parameters: The assertion URL received from the OP at
thereturn_to URL on the front-end server.
–Action: Receives the assertion URL, and veriﬁes the signature.
Upon successful veriﬁcation, it parses the return_to URL from
the assertion URL, and performs a stateless check_authentication
operation for the return_to URL with the op_endpoint_url . It
sets up a D-H shared key, and uses the key to securely verify
the following parameters in the assertion URL: op_endpoint ,
claimed_id ,identity ,return_to , and response_nonce .
–Response Parameters: Once successfully veriﬁed, it returns a suc-
cess message to Cloud Controller, and the openid.claimed_id .

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 50
Failure in any state of the veriﬁcation process sends back an error
status message.
A trace from performing OpenID authentication with the APIs on OpenStack
is included in appendix A.2 on page 79.
5.2.5 Modiﬁcations in Auth Manager
Any web server providing OpenID authentication has an inter nal mechanism
to link a local user to an OpenID Identiﬁer. Thus, we included an additional
credential for OpenStack users for OpenID authentication i n OpenStack. In
addition to the previously mentioned parameters (see secti on 2.3.2 on page
10), the user database in OpenStack includes the " openid " credential. The
OpenStack administrator is expected to add an OpenID Identi ﬁer for a user
to enable OpenID authentication for the user.
TheNova-OpenID Controller sends the openid.claimed_id toCloud
Controller upon successful veriﬁcation in the second phase of the authe n-
tication process. The Auth Manager then uses this OpenID URL to
retrieve the OpenStack user from the database, for that spec iﬁc authenticated
openid.claimed_id . This is similar to existing use cases for other APIs,
where the Auth Manager uses access keys, secret keys, or usernames to
retrieve the user information from the database.
5.2.6 Modiﬁcations in Nova-Manage
As explained in section 2.3.2.3 on page 13, the Nova-Manage module is an
admin tool for Auth Manager . Thus, we included an additional function
inNova-Manage , using which the administrator can add and modify the
OpenID information for the user.
The command for adding an OpenID URL for an OpenStack user is:
$ nova-manage user openid [user_openid_url]
Thus, the administrator adds the OpenID Identiﬁer to enable OpenID
authentication for the user during user creation. However, the current
implementation allows one-to-one mapping of OpenStack use rs to OpenIDs,
and a speciﬁc user can have only one OpenID Identiﬁer.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 51
5.2.7 Conﬁguration Presets
The prototype requires the following presets for executing OpenID authen-
tication in OpenStack.
1. The Dashboard/Django-Nova GUI server is running.
2. Django-Nova has an "admin" account with OpenStack. The Op enID
authentication is requested as a service on behalf of this ac count from
the front-end.
3. Dashboard/Django-Nova has a pre-speciﬁed " return_to " URL set by
the administrator.
4. OpenStack has the Nova-API andNova-OpenID-Controller services
running.
5. By default, the API Server runs on TCP port 8773, and the Nova-OpenID
Controller runs on TCP port 9988.
6. The administrator has created a user on OpenStack, and inc luded the
user’s OpenID Identiﬁer in the credentials.
Speciﬁc instructions and commands for conﬁguring the prese ts is included in
appendix A.1 on page 78.
5.2.8 Message Sequence
The signalling sequence in our prototype is shown in ﬁgure 5. 2. When the
User-Agent requests the index page from the front-end serve r, the login page
contains the " openid-identiﬁer " ﬁeld for entering the OpenID URL for the
user. Thus, the user enters his OpenID URL (User Identiﬁer or OP Identiﬁer)
and submits the value to the server.
GUI server then calls the OpenIDAuthReq EC2API on the OpenStack
API server. Additionally, it sets the value of the parameter "Name" as
"openid_url&return_to_url ".
The API Server receives the API request, and Nova-OpenID Con troller runs
the Yadis discovery protocol for the openid_url , to retrieve the OP endpoint
URL, and meta-information for the OP. The API server then gen erates the
response XML for the OpenIDAuthReq API call and sends it to the front-end
server to redirect the user.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 52
1. GET <index page>
2. HTML <openid_identifier>
3. GET <openid_url> submit form4. GET "OpenidAuthReq" EC2API
additional params:
name = "openid_url"&"return_to"5. Invoke API
– Yadis discovery protocol
– request OP-metadata
– Generate Redirection URL
User-Agent
GUI Server
OpenID Provider OpenStack Server
6. <?xml version="1.0" ?>
<OpenidAuthReqResponse>
<RedirectionURL>
…
params for redirection
…
</RedirectionURL>
</OpenidAuthReqResponse>
7. Parse XML
Construct 302 HTTP
redirection response 8. 302 HTTP Redirection
GET openid-redirection-url
9. User Authentication at OpenID Provider Website
Authenticate User : Generate OpenID Authentication Response : Redirect to "return_to"
10 a. 302 HTTP Redirection (openid_auth_response)
10 b. GET <return_to> URL11. GET "OpenidAuthVerify" EC2API
additional param:
name = "openid_auth_response"12. Invoke API
– Establish (D-H) key assoc
– Verify openid_auth_response
– Link OpenID -> User
– Return SUCCESS/FAILURE
14. Parse XML
If User details -> Allow Login
Else ->Failure13. <?xml version="1.0" ?>
<OpenidAuthVerifyResponse>
…
User details
…
</OpenidAuthVerifyResponse>
Figure 5.2: Signalling Sequence for OpenID Authentication in OpenStack
The GUI server uses the values, and sends an HTTP 302 Redirect ion to
the User-Agent. The User-Agent is then redirected to the OP. The OP
authenticates the user, and sends back the User-Agent to the return_to
URL at the GUI server with the assertion URL.
At the return_to URL, the GUI server invokes OpenIDAuthVerify EC2API.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 53
Additionally, it sets the value of the parameter " Name" as the whole OpenID
assertion URL received from the OP.
The API Server receives the request, and Nova-OpenID Contro ller runs the
veriﬁcation process with the OP. It runs the Yadis discovery protocol to
discover the OP services, and establishes a D-H shared key to verify the
assertion URL. Upon veriﬁcation, OpenStack then links a loc al user with the
openid.claimed_id .
The API server then creates the response XML for the OpenIDAuthVerify
API call with the user information, which the front-end serv er uses to allow
the user to log in. If the authentication was unsuccessful, i t returns an error
message in the response XML.
5.2.9 Prototype Action Flow
User-Agent
Dashboard
Django-NovaOpenID Provider
Cloud
Controller
API
ServerNova-OpenID
Controller
Auth
Manager
DB1.
2.
3.4.
5.6.7.
8.
9.
10.
11.12.13.14.15.
16.
17.
18.
19.
20.21.22.23.24.
25.
26.
27.b.27.a.28.29.
30.31.
32.33.34.GUI
ServerOpenStack
Server
Figure 5.3: Action Flow for OpenID Authentication in OpenSt ack
A detail description of the internal communication of the mo dules in the
architecture and the action ﬂow for the prototype is shown in ﬁgure 5.3. The
sequence of actions are as follows:

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 54
1: From the index page, the User-Agent submits the OpenID Ide ntiﬁer
URL for authentication.
2: Dashboard receives the OpenID URL and invokes an internal method
call to the Django-Nova framework.
3: Django-Nova invokes the "OpenidAuthReq" API to the back- end
OpenStack API server.
4, 5: API Server parses the parameters and invokes the openid_auth_req()
handler in Cloud Controller.
6: Cloud Controller sends a function request to the http://localhost:
9988/request URL in Nova-OpenID Controller.
7: Nova-OpenID Controller runs the Yadis discovery protoco l to retrieve
the OP end point URL, and OP’s other meta-information and spe ciﬁ-
cations.
8: Cloud Controller receives the parameters required for re directing the
User-Agent to the OP.
9, 10, 11: API Server receives the parameters, forms the resp onse XML object,
and sends it as response to the API call from Django-Nova.
12: Django-Nova parses the XML object, and sends the values t o Dash-
board.
13: Dasboard uses the values to populate a form template, and uses the
HTTP POST method to submit the values for redirection of the U ser-
Agent.
14, 15: User-Agent receives the redirection form, and is red irected to the OP
with the redirectional parameters.
16: The user authenticates himself to the OP using whichever authentica-
tion mechanism available at the OP.
17, 18: User-Agent is redirected back to the openid.return_to URL at the
front-end GUI server.
19: The return_to URL on Dashboard receives the assertion URL from the
OP, and invokes an internal method call to the Django-Nova fr amework
for veriﬁcation of the assertion URL.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 55
20: Django-Nova invokes the "OpenidAuthVerify" API to the b ack-end
OpenStack API server.
21, 22: API Server parses the parameters and invokes the openid_auth_verify()
handler in Cloud Controller.
23: Cloud Controller sends a function request to the http://localhost:
9988/verify URL in Nova-OpenID Controller.
24: Nova-OpenID Controller veriﬁes the signature, sets up a D-H shared
key, and securely veriﬁes values of all the parameter names w hich are
included in openid.signed .
25: If successfully veriﬁed, Nova-OpenID Controller retur ns a success
message, and the openid.claimed_id to the Cloud Controller. If
veriﬁcation was unsuccessful, it returns an error message.
26: If successfully veriﬁed, Cloud Controller requests Aut h Manager to
retrieve the user information from the user database. If ver iﬁcation was
unsuccessful, Cloud Controller forms a "user not found!" er ror message
and sends it back to the API server.
27, 28: Auth Manager interacts with the database to retrieve the user creden-
tials, and sends it to Cloud Controller.
29, 30, 31: API Server receives the parameters (from step 26 i n case of unsuccessful
veriﬁcation), forms the response XML object, and sends it as response
to the API call from Django-Nova.
32: Django-Nova parses the XML object, and sends the values t o Dash-
board.
33: Dasboard receives the values. If authentication was suc cessful, the
response values include the user information. If authentic ation was
unsuccessful, the response is a "user not found!" error mess age.
34: Thus, based on the received response values, Dashboard e ither allows
the user to log in to the interface, or displays a login error m essage.
The action ﬂow completes the sequence of using the OpenID-Au thentication-
as-a-Service APIs on OpenStack from the front-end GUI serve r. Thus, the
PDP and PAP is shifted to the back-end, and the front-end only acts as a
"dumb" PEP.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 56
5.3 OpenID Authentication APIs
This section gives the description of the API invocation and the possible
responses for the call. In addition to the OpenID parameters , both the APIs
require the mandatory parameters for all EC2APIs (see secti on 2.3.3.2 on
page 16).
5.3.1 OpenidAuthReq API
This section describes the format of OpenidAuthReq API call, and the
expected response XML objects.
5.3.1.1 API Invoke
As mentioned earlier in the conﬁguration presets (section 5 .2.7 on page 51),
the authentication service API is a service required to be in voked by an
admin user on OpenStack owned Django-Nova. Thus, the format for calling
theOpenidAuthReq EC2API is shown in table 5.1.
Table 5.1: Format for OpenidAuthReq EC2API
GET http://localhost:8773/services/Admin/
?AWSAccessKeyId=<admin_access_key>
&Action=OpenidAuthReq
&Name=<user_supplied_openid_url>&<gui_server_return _to_url>
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=<timestamp>
&Version=nova
&Signature=<signature_for_the_request>
5.3.1.2 Response Format
The response for OpenidAuthReq EC2API maintains the standard response
format for EC2APIs. If a valid OpenID Identiﬁer is supplied b y the user,
API Server responds with the variables for the redirection. Table 5.2 s hows
a successful response format.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 57
Table 5.2: Success Response Format for OpenidAuthReq EC2AP I
<?xml version="1.0" ?>
<OpenidAuthReqResponse xmlns="http://ec2.amazonaws.c om/doc/nova/">
<requestId>ec2api_request_id</requestId>
<input>
<openidClaimedId>openid_claimed_id</openidClaimedId >
<openidReturnTo>return_to_url?janrain_nonce=XXXX</o penidReturnTo>
<openidNs>openid_specification_version</openidNs>
<openidIdentity>user_supplied_openid</openidIdentit y>
<openidMode>checkid_setup</openidMode>
<openidRealm>return_to_url</openidRealm>
</input>
<form>
<action>op_endpoint_url</action>
<acceptCharset>UTF-8</acceptCharset>
<id>openid_message</id>
<enctype>application/x-www-form-urlencoded</enctype >
<method>post</method>
</form>
</OpenidAuthReqResponse>
If the user supplied an invalid OpenID URL, it responds with a n error
message, as shown in table 5.3.
Table 5.3: Failure Response Format for OpenidAuthReq EC2AP I
<?xml version="1.0"?>
<Response>
<Errors>
<Error>
<Code>NotFound</Code>
<Message>Invalid OpenID Provider</Message>
</Error>
</Errors>
<RequestID>ec2api_request_id</RequestID>
</Response>

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 58
5.3.2 OpenidAuthVerify API
This section describes the format of OpenidAuthVerify API call, and the
expected response XML objects.
5.3.2.1 API Invoke
Once the assertion URL is received at the front-end GUI serve r, it calls the
OpenidAuthVerify EC2API. The format for invoking the API is shown in
table 5.4.
Table 5.4: Format for OpenidAuthVerify EC2API
GET http://localhost:8773/services/Admin/
?AWSAccessKeyId=<admin_access_key>
&Action=OpenidAuthVerify
&Name=<assertion_url_from_op>
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=<timestamp>
&Version=nova
&Signature=<signature for the request>
5.3.2.2 Response Format
The response for he OpenidAuthVerify EC2API depends on the result of
the veriﬁcation. If successful, the response XML object con tains the user
information, which is similar to the response for the existi ngDescribeUser
EC2API [1]. The format for a successful response is shown in t able 5.5.
If the veriﬁcation was unsuccessful, the API Server responds with an error
message, as shown in table 5.6.
5.4 Dashboard/Django-Nova with OpenID
The Dashboard/Django-Nova framework uses the EC2APIs to pr ovide the
GUI service. For generating API calls, Django-Nova uses the python-boto
library [52]. Thus we used python-boto to implement the OpenidAuthReq and

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 59
Table 5.5: Success Response Format for OpenidAuthVerify EC 2API
<?xml version="1.0" ?>
<OpenidAuthVerifyResponse xmlns="http://ec2.amazonaw s.com/doc/nova/">
<requestId>ec2api_request_id</requestId>
<username>authenticated_user</username>
<secretkey>user_secret_key</secretkey>
<accesskey>user_access_key</accesskey>
<file>user_credential_file_url</file>
<openid>user_openid</openid>
</OpenidAuthVerifyResponse>
Table 5.6: Failure Response Format for OpenidAuthVerify EC 2API
<?xml version="1.0"?>
<Response>
<Errors>
<Error>
<Code>NotFound</Code>
<Message>
No user for OpenID:claimed_openid
</Message>
</Error>
</Errors>
<RequestID>ec2api_request_id</RequestID>
</Response>
OpenidAuthVerify API calls to OpenStack API Server, to perform OpenID-
Authentication-as-a-Service from the front-end.
In current implementation, Django-Nova owns an "admin" use r account in
OpenStack server. All initial requests from the server are m ade with the
"admin" user’s credentials. Once a user logs in successfull y, and Django-
Nova receives the user information, it then makes all furthe r requests with
the user’s credentials. Thus, the OpenID authentication se rvice is only usable
by an Admin user.
At ﬁrst, Dashboard/Django-Nova requests the OpenID authen tication ser-
vice. Section 5.3.1 on page 56 describes how to invoke the OpenidAuthReq
API, and the expected response XML.

CHAPTER 5. GOALS AND PROTOTYPE IMPLEMENTATION 60
Once Django-Nova receives the response, it parses the value s in the XML
object, and passes them on to Dashboard as name:value pairs. Dashboard
then uses the values to populate a form template for the HTTP 302
Redirection . The structure of the redirection form, along with a small
auto-submission script we used, is included in the appendix (see table A.1 in
section A.2 on page 79).
After the user has successfully authenticated himself at th e OP, the User-
Agent is redirected to the return_to URL on the Dashboard server. The
URL executes a method call to Django-Nova, to invoke the OpenidAuthReq
API. Section 5.3.2 on page 58 describes how to invoke the OpenidAuthVerify
API, and the expected response XML. A successful authentica tion returns the
user information, which Dashboard uses to populate the mana gerial interface
for the authenticated user.

Chapter 6
Analysis and Discussion
This chapter presents a post-implementation analysis and d iscussion of the
prototype and the security concerns. The goal of the thesis w as a proof-
of-concept for the integration of OpenID in OpenStack. Thus , this chapter
presents an evaluation and analysis on the architectural id eas rather than
thorough performance measurements.
6.1 Critical Security Points
Any web service is prone to security attacks. In theory, the l evel of security
of a system is equal to the security of the minimum secured poi nt in the
architecture.
In our implementation, the exposed interfaces are the GUI Server on the
front-end with the User-Agent , the API Server on the back-end with
theGUI Server , the OPend point with the User-Agent on the public
network, and the Nova-OpenID Controller back-end with the OP.
In all cases where the User-Agent is involved, using HTTPS is the safest
solution. Standard web services provide server-side certi ﬁcates to authen-
ticate the server to the User-Agent. However, in this case, i t is crucial
to authenticate the client to the web server. Thus, using bot h client-
side and server-side certiﬁcates for mutual authenticatio n is recommended.
Additionally, other mechanisms to protect the integrity of the messages
relayed through the User-Agent include nonce checking, and verifying
openid.sig for all the parameters included in openid.signed . It should
be noted that using an HTTPS connection increases the latenc y of the
authentication procedure.
61

CHAPTER 6. ANALYSIS AND DISCUSSION 62
For the API server, all RESTful requests include signatures with a pre-shared
secret between the GUI server and OpenStack. Thus, unless th e front-end
server is vulnerable to a compromise by an attacker, the conn ection to the
back-end can be considered as an integrity protected channe l. Currently,
the communication between Django-Nova and the API Server is over HTTP.
Hence, using SSL between the front-end Django-Nova and the A PI Server is
the most reasonable solution for providing conﬁdentiality . This is a standard
practice for all RESTful services. The API Server is an HTTP- supported
public interface, usable with other API clients (such as euc a-tools [4], and
python-nova client [15]). Security technologies such as IP Sec [33] are intended
for network level host-to-host security, rather than appli cation-to-application
security. Therefore, IPSec is not a recommended security so lution for the
RESTful API Server. However, HTTPS support in the OpenStack API
Server has not been implemented yet, and remains as a future t ask.
The veriﬁcation of the assertion URL by Nova-OpenID Control ler and the
OP occurs in the back-end. This is signiﬁcantly diﬀerent fro m regular
OpenID implementations, where the front-end is always the R P. However, the
back-end communication of Nova-OpenID Controller with the OP cannot be
considered hidden from an attacker. An attacker can sniﬀ pac kets from the
network to intercept the communication between Nova-OpenI D Controller
and the OP. Hence, following OpenID speciﬁcations, this com munication is
implemented over an encrypted channel with the D-H shared ke y between
Nova-OpenID Controller and the OP, as the OP is assumed to be o n the
public Internet.
An important part of the implementation on Nova-OpenID Cont roller was
the generation of redirection parameters. As the "return_t o" URL is speciﬁed
by the front-end, we ensured its integrity in the veriﬁcatio n process by making
sure it is included in the " openid.signed " parameter list, and the parameter
values are all included in the " openid.sig " signature.
However, there is still scope for an attacker to manipulate t he information.
As explained in section 3.3 on page 32, the solution can be vul nerable to
Discovery Tampering, Adversary Relay Proxy, and DoS attack s.
Session management between the User-Agent and Dashboard/D jango-Nova
front-end is another area where the security should be impro ved. Authenti-
cation of the user is done in the back-end. However, OpenStac k still has to
rely on the front-end to maintain the user session. Services on OpenStack
are RESTful services, and no session information is stored, while the front-
end is a session-based service point for the User-Agent. It i s contradictory
with the design principles of RESTful services to maintain s uch session based

CHAPTER 6. ANALYSIS AND DISCUSSION 63
security. Therefore, OpenStack trusts the front-end Dashb oard/Django-Nova
to manage the user session.
6.2 Use Case Study
The implementation of OpenID on OpenStack was tested agains t two speciﬁc
use cases. The following sections present the details for th e use cases.
6.2.1 Standard OpenID Providers
Our implementation follows all the speciﬁcations of OpenID 2.0 [54, 13].
Thus, authentication in OpenStack using OpenID is supporte d for all
standard OpenID providers supporting OpenID 2.0.
We have veriﬁed use cases for authentication using our own im plemented
OP, and also with OpenIDs from Google ,Yahoo , and MyOpenID . Table 6.1
summarizes the features of the OpenID providers. In each cas e, we were
concerned with the returned value for openid.claimed_id , which is the user
Identiﬁer the OpenStack administrator is required to inclu de in the user
credentials.
Table 6.1: Standard OpenID Providers
OP Comments
Google OP Identiﬁer https://www.google.com/accounts/o8/id
returns random string as Identiﬁer. User Identiﬁer
https://profiles.google.com/username returns user speciﬁed
Identiﬁer. Supports OpenID 2.0.
Yahoo https://me.yahoo.com/username returns user speciﬁed Identiﬁer.
Supports OpenID 2.0.
MyOpenID http://username.myopenid.com/ returns user speciﬁed Identiﬁer.
Insecure HTTP OP endpoint. Supports OpenID 2.0.
6.2.2 GBA Provider
3rd Generation Partnership Project (3GPP) speciﬁes the Gen eric Bootstrap-
ping Architecture (GBA) [23] as a mechanism to authenticate devices. It
uses cellular technology with the Internet to provide authe ntication services

CHAPTER 6. ANALYSIS AND DISCUSSION 64
to mobile devices. As an extension, the 3GPP also speciﬁes a s tandardization
for the integration of OpenID with GBA [22, 24].
Ericsson Labs provide a GBA based authentication service in their Identity
Management (IDM) portal [35]. Currently, it can be used over the Internet,
making any device behave as a next generation mobile device, by installing
theSoftSim application on the device, available on the portal.
In our use case, we used an Android enabled mobile device for a ccessing
the OpenStack GUI. We used the GBA with OpenID mechanism to
authenticate the Android device with the SoftSim application. Ericsson
IDM uses the OP Identiﬁer https://idm.labs.ericsson.net to initiate
the OpenID authentication. A successful authentication re turns a user
speciﬁed https://idm.labs.ericsson.net/portal/id/username Identi-
ﬁer from the portal.
6.2.3 Performance Evaluation
In our use cases, we found that the execution time varied with the diﬀerent
OpenID providers. We were running the OpenStack server back -end and the
Dashboard/Django-Nova front-end GUI server on the same mac hine. The
server was running the Ubuntu 10.04.2 LTS Lucid 64-bit operating system,
on a Tower MacPro4.1, with 8GB RAM, and a 2.27GHz Intel(R) Xeo n(R)
16 Core 64-bit processor.
We captured network packets and calculated the time diﬀeren ces to evaluate
the performance of our prototype. We recorded 30 observatio ns for each
OpenID provider. The times were calculated based on two phas es. The
"Request" phase includes the time from the User-Agent submi tting the
OpenID Identiﬁer until the User-Agent reaches the OP endpoi nt URL. The
"Veriﬁcation" phase includes the time from the authenticat ed User-Agent
being redirected from the OP, until the time when the user is l ogged into the
Dashboard interface.
Furthermore, we recorded another 30 measurements for each p rovider,
when the user is already signed in at the OP. The user had a seam less
SSO experience, without the need to re-authenticate at the O P. The
timing includes the time for the user to submit their OpenID I dentiﬁer on
the Dashboard interface, and directly log in without any add itional user
interaction.
The measurements had an approximately Gaussian distributi on. Thus, we
calculated the mean of the readings. The recorded measureme nts are shown

CHAPTER 6. ANALYSIS AND DISCUSSION 65
in ﬁgure 6.1. The graph shows the mean of each set of readings, along with
the population standard deviation for each OP.
Figure 6.1: Time Measurements for OpenID Authentication
As shown in the graph, the request phase for all the OPs has sma ll standard
deviation compared to the veriﬁcation phase and the SSO timi ngs. The
request phase only requires the Nova-OpenID Controller to d iscover the OP
meta-information, and thus exhibits a relatively consiste nt behaviour.
The table shows the ratio of the veriﬁcation phase to the requ est phase
for each provider. It can be seen that, except for MyOpenID , all providers
require approximately double the time in the veriﬁcation ph ase compared to
the request phase. The veriﬁcation phase includes setting u p a D-H shared
key, and encryption and decryption of all information while verifying the
assertion URL. Thus, Nova-OpenID Controller requires more time in the
second phase. A higher standard deviation in the readings is understandable
because of the varying processing times both at the Nova-Ope nID Controller
and at the OP end.
The time measurements for the providers show that MyOpenID takes the

CHAPTER 6. ANALYSIS AND DISCUSSION 66
least time in all cases. This is because MyOpenID uses only a basic HTTP
connection and is thus faster, but unsecured .
For all OPs, the SSO timing is greater than the summation of th e authen-
tication and the veriﬁcation phase timings. The ﬁrst two mea surements
did not include the user interaction while performing authe ntication at the
OP. However, in the measurements for SSO, the User-Agent req uires time
for the extra processing needed to authenticate itself to th e OP with the
cookies stored in the device. The SSO timings for all OPs disp lay the highest
standard deviation. This is because the timing includes pro cessing delays at
the User-Agent (to retrieve the cookies), at the OP, and at No va-OpenID
Controller. As because these three entities have varying pe rformance, the
recorded timing intervals had a comparatively high varianc e.
Furthermore, we measured the internal timing between the No va-OpenID
Controller and Cloud Controller to evaluate the performanc e of the internal
module. We recorded the duration of time for the Cloud Contro ller to
send a request to Nova-OpenID Controller and receive a respo nse, for both
theopenid_auth_req andopenid_auth_verify API handlers. We recorded
30 measurements for each of the OPs for each operation. The re corded
measurements are shown in ﬁgure 6.2. The graph shows the aver age duration
of time between the request and the response for the authenti cation request
and the authentication veriﬁcation along with the standard deviation for each
of the OPs.
The graph in ﬁgure 6.2 for the internal timing measurements s hows a similar
pattern to the external measurements in ﬁgure 6.1. The stand ard deviations
for all the OPs were also consistent.
However, ﬁgure 6.2 does not show the timing for the veriﬁcati on phase to be
twice the time required for the request phase as in ﬁgure 6.1. Additionally,
the sum of the internal timings on ﬁgure 6.2 is much lower comp ared to the
external timing in ﬁgure 6.1 for all the OPs. This is because t he external
measurements include the time required for the API Server to process the
variables and generate the response XML for the API call, the time required
for Dashboard/Django-Nova front-end to process the data an d generate the
HTML view and, primarily, the time required for the authenti cation process
at the OP end point.
However, the performance of the prototype and the timing mea surements
depend largely on the hardware conﬁguration of the server. A dditionally,
OpenStack does not incorporate any eﬃciency improvement me chanisms at
present, and the design and architecture of the whole system is still evolving.

CHAPTER 6. ANALYSIS AND DISCUSSION 67
Figure 6.2: Time Measurements for Nova-OpenID Controller
6.3 Version Information
OpenStack released its initial version, Austin, in October 2010. The second
release version, Bexar, came out in February 2011.
Our implementation was integrated with the Bexar release. A fter a successful
implementation with Bexar, we then integrated our solution with Cactus, the
third release, which came out in April 2011.
Diablo, the fourth release of OpenStack is scheduled to be re leased in Septem-
ber 2011. However, beginning with the Diablo release, the au thentication
framework design is supposed to utilize a new architecture. It will integrate
theKeyStone project [49] as the authentication module, the design of whi ch
is still evolving.

CHAPTER 6. ANALYSIS AND DISCUSSION 68
6.4 Discussion
The goal of this thesis project was to introduce a ﬂexible dec entralized
authentication mechanism for cloud computing platforms. S tudying the
usability and availability of services, we chose OpenID as t he authentication
mechanism. After extensive research on open-source cloud m iddleware
solutions, we chose OpenStack to continue our work. However , OpenID has
its own ﬂaws and vulnerabilities, and OpenStack also has its limitation and
complexities.
After achieving our initial goal, we conducted further rese arch, and con-
verged on the idea of implementing OpenID-Authentication- as-a-Service
APIs in OpenStack. In addition to fulﬁlling the requirement to perform
authentication with OpenID, we introduced the concept of pe rforming the
authentication in a rather unusual manner. We divided the au thentication
process into two phases, and implemented the processes with two separate
APIs on the API Server.
During the thesis work, we faced certain technical challeng es. Section
5.1 on page 43 discusses the way each of the issues were handle d. The
prototype incorporated all of the standard security practi ces and meets the
speciﬁcations of the technologies being used.
One of the most challenging parts of the work was to logically adapt the
dual PDP scenario into a single PDP. Even with a working desig n, the
implementation required extensive exploration of the Open ID parameters
to divide the functionality of a standard RP in to the necessa ry components.
Veriﬁcation of the parameters and inclusion of the paramete rs in the signature
was one of the crucial features of the implementation.
Another diﬃcult design task was choosing the point of integr ation of the
features in the OpenStack architecture. We believe that we h ave selected an
interesting approach, by adding the Nova-OpenID Controlle r as a separate
module and implementing an internal interface with the Clou d Controller.
This was especially important from the perspective of inter nal network
security. As this module interacted with the OP on the public Internet, the
separation provides the required abstraction of the intern al network from the
public Internet.
One of the features of the implementation is that it only supp orts OpenID
version 2.0. This was a requirement as we needed to implement a RESTful
service, and a similar "stateless" mode is only supported in OpenID 2.0. This
cannot be viewed as a limitation, as OpenID 2.0 is considered to be more
secure than its previous versions.

Chapter 7
Conclusions and Future Work
The evolution of cloud computing is driving the next generat ion of internet
services. In addition to proprietary platforms, multiple o pen-source middle-
ware solutions are available on the Internet.
Currently, all middleware support platform speciﬁc techno logies for authen-
tication and access control. In our research we chose OpenSt ack as our open-
source cloud platform. OpenStack allows access via its two s et of RESTful
APIs: the EC2APIs and the OSAPIs. These APIs use access keys a nd secret
keys to authenticate users in the framework when accessing s ervices.
Nonetheless, the adoption of these new technologies must be easy for the
users. To improve usability, OpenStack oﬀers a graphical in terface with the
Dashboard/Django-Nova framework. However, the current ar chitecture of
OpenStack lacks speciﬁc GUI based services. Thus, the Dashb oard/Django-
Nova framework uses the set of EC2APIs to provide HTML views o f the GUI.
For initial authentication, the front-end incorporates a s eparate username
and password based validation mechanism. This introduces a dual PDP
scenario, which is not a recommended practice for web servic es.
In this thesis, we introduced a ﬂexible decentralized authe ntication service
for the front-end. We selected OpenID as an open-source auth entication
platform. OpenID has its own advantages for web services, wh ich include
improvements in usability and seamless SSO experience for t he users.
OpenID allows users to choose identities from multiple prov iders on the
Internet, use a range of authentication mechanisms dependi ng upon the
mechanisms supported by the provider, and to access multipl e service points
on the Internet with the same OpenID Identiﬁer.
In our design, OpenID authentication in the front-end is use d as a service
69

CHAPTER 7. CONCLUSIONS AND FUTURE WORK 70
from the back-end OpenStack server. As a result, we were able to shift
the dual points of decision making and perform the authentic ation at a
single PDP in the back-end. For our implementation, we explo red OpenID
authentication. We were able to divide the mechanism into tw o phases:
the authentication request and the authentication veriﬁca tion phase. The
two phases in the authentication process were then implemen ted with two
separate APIs.
The design was implemented on OpenStack. We used Dashboard/ Django-
Nova as the front-end GUI, and implemented the APIs as EC2API s. The
two implemented APIs on the OpenStack API server are OpenidAuthReq
and OpenidAuthVerify . Additionally, we added the Nova-OpenID
Controller a new module in the OpenStack architecture. This module
communicates with the Cloud Controller over an internal HTTP interface,
and with the OP on the public Internet over another interface . Furthermore,
we extended the functionality of the Nova-Manage administrator tool, to
add and modify the OpenID credentials for existing OpenStac k users.
The OpenID support for the prototype is designed only for use with OpenID
version 2.0. The prototype implementation was successfull y tested against
standard OpenID providers on the Internet supporting OpenI D 2.0. The
use cases were evaluated against OpenID Identiﬁers from Google ,Yahoo ,
andMyOpenID , along with a GBA based authentication mechanism from
Ericsson IDM Services .
The Nova-OpenID Controller on the back-end incorporates secure au-
thentication and veriﬁcation of the OpenID assertion URL wi th the OP.
Therefore, secure interaction with the OP over HTTPS is supp orted.
However, Nova-OpenID Controller is able perform the authen tication process
over an insecure HTTP connection, depending upon the OP’s ca pabilities. In
our timing measurements, we found that using HTTPS requires more time
compared to using HTTP. This is a basic trade-oﬀ between secu rity and
performance of any system. Execution time traces of perform ing OpenID
authentication in OpenStack is included in appendix A on pag e 78.
In our thesis, we developed a prototype as a the proof-of-con cept for
using OpenID-Authentication-as-a-Service from front-en d GUI servers. The
security of the solution follows the relevant standards. Th is concept can be
applied to similar architectures, where there is a separati on of the PDP on
the service back-end, and a PEP on the "dumb" front-end.

CHAPTER 7. CONCLUSIONS AND FUTURE WORK 71
Future Work
The research performed during this thesis project revealed further possibili-
ties. The ﬁrst objective would be to introduce greater ﬂexib ility in the choice
of authentication mechanisms for the user. Second, one shou ld introduce
open platforms for authorization delegation in OpenStack.
To provide ﬂexibility in the choice of authentication on Ope nStack, we
suggest that other authentication platforms, such as Shibb oleth/SAML, be
considered. Shibboleth is an organization centric authent ication mechanism.
The authentication tokens and other information are exchan ged between the
authentication provider and the service provider on the bac k-end.
A use case for Shibboleth authentication is where an organiz ation has a
service agreement with an OpenStack cloud provider. Thus, a ny user from
the organization should be able to use the OpenStack service s using his or
her organization centric identity using Shibboleth authen tication.
To provide a generic solution for authentication, we aim to d esign a common
Authentication-as-a-Service API in OpenStack. This API wi ll allow the
front-end GUI to use any method of authentication based on th e user’s choice.
The second objective would be to introduce open authorizati on platforms in
OpenStack. We will consider OAuth [11] as the most appropria te open-
source authorization mechanism. OAuth is a user centric aut horization
delegation speciﬁcation, and allows two parties to securel y interchange
speciﬁc information about authorized resources.
We have already performed an applicability analysis of OAut h on OpenStack.
A possible use case for OAuth is when a user has accounts on two OpenStack
providers. With OAuth, the user will be able to deﬁne authori zed resources
on provider A. Then, the user can utilize resources from prov ider B, with
provisions for dynamic scaling of resources to provider A. A high level design
of delegated authorization with OAuth in OpenStack is inclu ded in appendix
B on page 84.

Bibliography
[1] Amazon AWS EC2 API Reference, http://docs.amazonweb-
services.com/awsec2/latest/apireference/, last access ed 30th April
2011.
[2] Amazon Simple Storage Service (Amazon S3),
http://aws.amazon.com/s3/, last accessed 30th April 2011 .
[3] Amazon Web Services (AWS), http://aws.amazon.com, las t accessed
30th April 2011.
[4] Euca-Tools, Eucalyptus Community, http://open.eucal yptus.com/wiki-
/toolsecosystem, last accessed 10th May 2011.
[5] Eucalyptus Open Source Cloud Platform, http://www.euc alyptus.com,
last accessed 5th March 2011.
[6] Google App Engine, https://code.google.com/appengin e, last accessed
15th March 2011.
[7] Hadoop, http://hadoop.apache.org/, last accessed 10t h March 2011.
[8] Libvirt Online Working Group, The Virtualization API,
http://libvirt.org, last accessed 25th April 2011.
[9] LiveJournal OpenID Services, http://www.livejournal .com, last ac-
cessed 1st February 2011.
[10] MyOpenID OpenID Services, https://www.myopenid.com , last accessed
14th June 2011.
[11] OAuth Community Site, http://oauth.net/, last access ed 15th june
2011.
[12] OpenID Attribute Exchange 1.0, http://openid.net/sp ecs/openid-
attribute-exchange-1_0.html, last accessed 30th May 2011 .
72

BIBLIOGRAPHY 73
[13] OpenID Foundation, http://openid.net, last accessed 14th June 2011.
[14] OpenNebula, http://opennebula.org, last accessed 15 th March 2011.
[15] Python-Nova Client, http://pypi.python.org/pypi/p ython-
novaclient/2.3, last accessed 10th may 2011.
[16] Python-Openid 2.2.5, http://pypi.python.org/pypi/ python-openid, last
accessed 5th May 2011.
[17] Rackspace US, http://www.rackspace.com, last access ed 3rd March
2011.
[18] SalesForce CRM & Cloud Computing, www.salesforce.com , last accessed
3rd March 2011.
[19] Yadis 1.0, The Identity and Accountability Foundation for Web 2.0,
http://yadis.org, last accessed 5th June 2011.
[20] Yahoo OpenID Services, http://openid.yahoo.com, las t accessed 14th
June 2011.
[21] Twenty-one experts deﬁne cloud computing. In SYS-CON Media, Inc.,
http://virtualization.sys-con.com/node/612375 . January 2009.
[22]3rd Generation Partnership Project. 3GPP TR 33.924 .
Identity management and 3gpp security interworking; ident ity
management and generic authentication architecture (gaa) interworking,
(release 9). http://www.3gpp.org/ftp/specs/html-info/ 33924.htm, 2009.
[23]3rd Generation Partnership Project. 3GPP TS 33.220 .
Technical speciﬁcation group services and system aspects; generic
authentication architecture (gaa); generic bootstrappin g architecture
(release 8), http://www.3gpp.org/ftp/specs/html-info/ 33220.htm, 2009.
[24]Ahmed, A. S. A user friendly and secure openid solution for smart
phone platforms. Master’s thesis, Faculty of Information a nd Natural
Sciences, School of Science and Technology, Aalto Universi ty, June 2010.
[25]Almulla, S., and Yeun, C. Y. Cloud computing security
management. In Engineering Systems Management and Its Applications
(ICESMA), 2010 Second International Conference on (30 2010-april 1
2010), pp. 1 –7.

BIBLIOGRAPHY 74
[26]Berners-Lee, T., Fielding, R., and Masinter, L. Uniform
Resource Identiﬁer (URI): Generic Syntax. Internet Request for
Comments RFC 3986 (Standard) (Jan. 2005).
[27]Cloud.com . Cloudstack, http://cloud.com, last accessed 2nd March
2011.
[28]Crockford, D. The application/json Media Type for JavaScript
Object Notation (JSON). Internet Request for Comments RFC 4627
(Informational) (July 2006).
[29]Dhamija, R., and Dusseault, L. The seven ﬂaws of identity
management: Usability and security challenges. Security Privacy, IEEE
6, 2 (march-april 2008), 24 –29.
[30]Di-Lucca, G., Fasolino, A., Mastoianni, M., and Tramon-
tana, P. Identifying cross site scripting vulnerabilities in web
applications. In Web Site Evolution, 2004. WSE 2004. Proceedings.
Sixth IEEE International Workshop on (sept. 2004), pp. 71 – 80.
[31]Dierks, T., and Allen, C. The TLS Protocol Version 1.0. Internet
Request for Comments RFC 2246 (Proposed Standard) (Jan. 1999).
Obsoleted by RFC 4346, updated by RFCs 3546, 5746.
[32]Diffie, W., and Hellman, M. New directions in cryptography. In
IEEE Transactions on Information Theory (nov 1976), vol. 22, pp. 644
– 654.
[33]Doraswamy, N., and Harkins, D. IPSEC: The New Security
Standard for the Internet, Intranets, and Virtual Private N etworks .
Prentice Hall, 1999.
[34]Erdos, M., and Cantor, S. Shibboleth architecture protocols and
proﬁles, http://shibboleth.internet2.edu/shibboleth- documents.html.
[35]Ericsson Labs Identity Management Framework .
https://labs.ericsson.com/developer-community/blog/ identity-
management-framework-now-available-download, last acc essed 15th
May 2011.
[36]Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and
Berners-Lee, T. Hypertext Transfer Protocol – HTTP/1.1. Internet
Request for Comments RFC 2068 (Proposed Standard) (Jan. 1997).
Obsoleted by RFC 2616.

BIBLIOGRAPHY 75
[37]Fielding, R. T. Architectural Styles and the Design of Network-based
Software Architectures . PhD thesis, University of California, Irvine,
2000.
[38]Foster, I. and Yong Zhao and Raicu, I. and Lu, S. Cloud
Computing and Grid Computing 360-Degree Compared. In Grid
Computing Environments Workshop, 2008. GCE ’08 (November 2008),
pp. 1 – 10.
[39]Garber, L. Denial-of-Service Attacks Rip the Internet. Computer Vol-
ume 33 , Number 4 (April 2000), 12–17, doi: 10.1109/MC.2000.83931 6.
[40]Gollmann, D. Computer security. Wiley Interdisciplinary Reviews:
Computational Statistics 2 , 5 (2010), 544–554.
[41]Google . Google OpenID Services,
http://code.google.com/apis/accounts/docs/openid.ht ml, last accessed
15th March 2011.
[42]Han, H., Kim, S., Jung, H., Yeom, H., Yoon, C., Park, J., and
Lee, Y. A restful approach to the management of cloud infrastructur e.
InIEEE International Conference on Cloud Computing (2009), pp. 139–
142.
[43]Kumaran, S., Liu, R., Dhoolia, P., Heath, T., Nandi, P., and
Pinel, F. A restful architecture for service-oriented business proc ess
execution. In Proc. IEEE Int. Conf. e-Business Engineering ICEBE ’08
(2008), pp. 197–204.
[44]Lee, H. K., Malkin, T., and Nahum, E. Cryptographic strength
of ssl/tls servers: current and recent practices. In Proceedings of the 7th
ACM SIGCOMM conference on Internet measurement (New York, NY,
USA, 2007), IMC ’07, ACM, pp. 83–92.
[45]Leicher, A., Schmidt, A., Shah, Y., and Inhyok, C. Trusted
computing enhanced openid. In Internet Technology and Secured
Transactions (ICITST), 2010 International Conference for (nov. 2010),
pp. 1 –8.
[46]Lindholm, A. Security Evaluation of the OpenID Protocol. Master’s
thesis, School of Computer Science and Communication, Roya l Institute
of Technology (KTH), 2009.

BIBLIOGRAPHY 76
[47]Microsoft . MSDN CardSpace Token Acquisition Protocol
Speciﬁcation (MS-CTAP), http://msdn.microsoft.com/en-
us/library/cc717408(v=prot.10).aspx, last accessed 25t h may 2011.
[48]Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G.,
Soman, S., Youseff, L., and Zagorodnov, D. The eucalyptus
open-source cloud-computing system. In Proceedings of the 2009 9th
IEEE/ACM International Symposium on Cluster Computing and the
Grid (Washington, DC, USA, 2009), CCGRID ’09, IEEE Computer
Society, pp. 124–131.
[49]OpenStack Keystone Project . http://wiki.openstack.org/openstack-
authn, last accessed 25th May, 2011.
[50]Oppliger, R. Microsoft .net passport and identity management.
Information Security Technical Report 9 , 1 (2004), 26 – 34.
[51]Philpott, R., Maler, E., Ragouzis, N., Hughes, J., Madsen,
P., and Scavo, T. OASIS Open 2008, Security Assertion
Markup Language (SAML) V2.0 Technical Overview, Committee
Draft 02, http://docs.oasis-open.org/security/saml/po st2.0/sstc-saml-
tech-overview-2.0.html.
[52]Python Boto . http://code.google.com/p/boto/, last accessed 15th
may, 2011.
[53]Rackspace US, Inc. Openstack compute developer guide api 1.0, api
v1.0, january 2011.
[54]Recordon, D., and Reed, D. Openid 2.0: a platform for user-centric
identity management. In Proceedings of the second ACM workshop on
Digital identity management (New York, NY, USA, 2006), DIM ’06,
ACM, pp. 11–16.
[55]Richardson, L., and Ruby, S. RESTful Web Services . O’Reilly
Media, May 2007.
[56]Rieger, S. User-centric identity management in heterogeneous
federations. In Internet and Web Applications and Services, 2009. ICIW
’09. Fourth International Conference on (may 2009), pp. 527 –532.
[57]Rosenberg, J., and Remy, D. Securing Web Services with
WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML
Signature, and XML Encryption . Pearson Higher Education, 2004.

BIBLIOGRAPHY 77
[58]Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. Role-
based access control models. Computer 29 , 2 (feb 1996), 38 –47.
[59]Sovis, P., Kohlar, F., and Schwenk, J. Security Analysis of
OpenID. In Sicherheit’10 (2010), vol. 170, F. C. Freiling, pp. 329–340.
[60]van Delft, B., and Oostdijk, M. A security analysis of openid. In
Policies and Research in Identity Management , E. de Leeuw, S. Fischer-
Hübner, and L. Fritsch, Eds., vol. 343 of IFIP Advances in Information
and Communication Technology . Springer Boston, 2010, pp. 73–84.
[61]Wachob, G., Reed, D., Chasen, L., Tan, W., and Churchill,
S.Extensible resource identiﬁer (xri) resolution v2.0, http ://docs.oasis-
open.org/xri/2.0/specs/xri-resolution-v2.0.pdf.
[62]Watanabe, R., and Tanaka, T. Federated authentication
mechanism using cellular phone – collaboration with openid . In
Information Technology: New Generations, 2009. ITNG ’09. S ixth
International Conference on (april 2009), pp. 435 –442.
[63]World Wide Web Consortium (W3C) . Simple Object Access
Protocol (SOAP), http://www.w3.org/tr/soap, last access ed 14th April
2011.

Appendix A
Executing OpenID in
OpenStack
This section includes some execution instructions and trac es from the
execution of the OpenID authentication mechanism on OpenSt ack.
A.1 Setup Information
This section provides the setup instructions for the OpenSt ack prototype to
function.
The ﬁrst requirement is to set up the database.
$ InstallationDir/bin/nova-manage db sync
An admin user is created on OpenStack for the Dashboard/Djan go-Nova
framework, with the access key "admin", and the secret key "a dmin". Another
regular user, "rasib" is then created, who will be using the s ervice. The access
and secret key is automatically generated by OpenStack in th is case.
$ InstallationDir/bin/nova-manage user admin dashboardA dmin admin admin
$ InstallationDir/bin/nova-manage user admin rasib
Having user "rasib" created, we would then add the user’s Ope nID Identiﬁer
with his OpenStack credentials. In this case, we would be usi ng his Google
OpenID information, which would be used to log into OpenStac k GUI.
$ InstallationDir/bin/nova-manage user openid rasib http s://profiles.
78

APPENDIX A. EXECUTING OPENID IN OPENSTACK 79
google.com/rasib
A project is created on OpenStack, with the Dashboard admini strator as the
project manager.
$ InstallationDir/bin/nova-manage project create projec t1 dashboardAdmin
Finally, a small network for the pool of IP addresses for the V Ms is created.
$ InstallationDir/bin/nova-manage network create 172.16 .0.0/16 1 16
Having done all of it, it is then required to run the OpenStack services with
the following commands.
$ InstallationDir/bin/nova-api
$ InstallationDir/bin/nova-objectstore
$ InstallationDir/bin/nova-compute
$ InstallationDir/bin/nova-network
$ InstallationDir/bin/nova-scheduler
$ InstallationDir/bin/nova-volume
$ InstallationDir/bin/nova-ajax-console-proxy
$ InstallationDir/bin/nova-openid
Finally, after setting up OpenStack services, we would then run the
Dashboard/Django-Nova GUI service.
$ DashboardDir/tools/with_venv.sh DashboardDir/dashbo ard/manage.py runserver
0.0.0.0:8080
A.2 Execution Trace
We had run the services on the Nomadic Lab network, on host n25. Thus,
initially, the User-Agent requests the index page from Dash board from:
http://n25.nomadiclab.com:8080
The user then types his OpenID URL in the openid-identiﬁer bo x, and
submits the value. Thus, the OpenidAuthReq API is called, with the
appropriate parameters. The API request looks like the foll owing:

APPENDIX A. EXECUTING OPENID IN OPENSTACK 80
GET http://n25.nomadiclab.com:8773/services/Admin/
?AWSAccessKeyId=admin
&Action=OpenidAuthReq
&Name=profiles.google.com/rasib\
&http://n25.nomadiclab.com:8080/openid/verify/
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=2011-03-23T07:20:55
&Version=nova
&Signature=FnNUPULRvynIjYG6ylVWK9PrjWj3NCmWrfOdgzNY 8s=
As this API is called, the following messages on the Nova-Ope nID Controller
service describes its functions:
OpenID identifier: profiles.google.com/rasib
Service redirection URL: http://n25.nomadiclab.com:808 0/openid/verify/
Trust root included: http://n25.nomadiclab.com:8080/op enid/verify/
Generated checkid_setup request to https://www.google.c om/accounts/
o8/ud?source=profiles using stateless mode
With the discovered information by Nova-OpenID Controller , it returns the
redirectional parameters in the response XML for the front- end to redirect
the User-Agent to Google for user authentication.
<?xml version="1.0" ?>
<OpenidAuthReqResponse xmlns="http://ec2.amazonaws.c om/doc/nova/">
<requestId>M84ZV2V9T9ZLUZRG5VEP</requestId>
<input>
<openidClaimedId>https://profiles.google.com/rasib8 5</openidClaimedId>
<openidReturnTo>http://10.0.0.25:8080/openid/verify /
?janrain_nonce=2011-03-23T07%3A20%3A56ZLnMsYN
</openidReturnTo>
<openidNs>http://specs.openid.net/auth/2.0</openidN s>
<openidIdentity>https://profiles.google.com/rasib85 </openidIdentity>
<openidMode>checkid_setup</openidMode>
<openidRealm>http://10.0.0.25:8080/openid/verify/</ openidRealm>
</input>
<form>
<action>https://www.google.com/accounts/o8/ud?sourc e=profiles</action>
<acceptCharset>UTF-8</acceptCharset>
<id>openid_message</id>
<enctype>application/x-www-form-urlencoded</enctype >
<method>post</method>
</form>
</OpenidAuthReqResponse>

APPENDIX A. EXECUTING OPENID IN OPENSTACK 81
Using the response XML, Dashboard then uses a form to populat e the ﬁelds
and an auto-submission script to POST to redirect the user. T he format of
the form is shown in table A.1.
Table A.1: Dashboard HTTP 302 Redirection Form
<body onload="document.forms[0].submit();">
<h1>OpenID transaction in progress</h1>
<form id="{{formId}}" action="{{formAction}}"
method="{{formMethod}}"
accept-charset="{{formAcceptCharset}}"
enctype="{{formEnctype}}">
<input type="hidden" name="openid.return_to"
value="{{inputOpenidReturnTo}}"/>
<input type="hidden" name="openid.realm"
value="{{inputOpenidRealm}}"/>
<input type="hidden" name="openid.ns"
value="{{inputOpenidNs}}"/>
<input type="hidden" name="openid.claimed_id"
value="{{inputOpenidClaimedId}}"/>
<input type="hidden" name="openid.mode"
value="{{inputOpenidMode}}"/>
<input type="hidden" name="openid.identity"
value="{{inputOpenidIdentity}}"/>
<input type="submit" value="Continue"/>
</form>
<script>
var elements = document.forms[0].elements;
for (var i = 0; i < elements.length; i++) {
elements[i].style.display = "none";
}
</script>
</body>
The User-Agent is redirected to the OP, and once the user auth enticates
himself, he is sent back to the return_to URL on Dashboard/Django-Nova.
Dashboard/Django-Nova then calls the OpenidAuthVerify API.

APPENDIX A. EXECUTING OPENID IN OPENSTACK 82
GET http://n25.nomadiclab.com:8773/services/Admin/
?AWSAccessKeyId=admin
&Action=OpenidAuthVerify
&Name=/openid/verify/
?janrain_nonce=2011-03-23T07:20:56ZLnMsYN
&openid.ns=http://specs.openid.net/auth/2.0
&openid.mode=id_res
&openid.op_endpoint=https://www.google.com/
accounts/o8/ud?source=profiles
&openid.response_nonce=2011-03-23T07:20:58ZQ02wNXOY IlqBcQ
&openid.return_to=http://10.0.0.25:8080/openid/veri fy/
?janrain_nonce=2011-03-23T07:20:56ZLnMsYN
&openid.assoc_handle=AOQobUd67rDCBApRSNOX2lBiEA_
jmOuOm0NcNzI4im8sDgz6KGo1iZ1E
&openid.signed=op_endpoint,
claimed_id,
identity,
return_to,
response_nonce,
assoc_handle
&openid.sig=9m2AfSwsGQ/40frxzNJlB4KqRbk=
&openid.identity=https://profiles.google.com/rasib
&openid.claimed_id=https://profiles.google.com/rasi b
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=2011-03-23T07:20:58
&Version=nova
&Signature=8jnIm7Ede/KbNYuAcKu73Yx9aT MxHyLNijjwhAoS BE=
As this API is called, the following messages on the Nova-Ope nID Controller
service describes its functions:
No pre-discovered information supplied.
Performing discovery on https://profiles.google.com/ra sib
Received id_res response from https://www.google.com/
accounts/o8/ud?source=profiles using association
AOQobUd67rDCBApRSNOX2lBiEA_jmOuOm0NcNzI4im8sDgz6KGo 1iZ1E
Using OpenID check_authentication
op_endpoint
claimed_id
identity
return_to
response_nonce
assoc_handle
Status: success

APPENDIX A. EXECUTING OPENID IN OPENSTACK 83
Identifier: https://profiles.google.com/rasib
After the veriﬁcation is completed successfully, Auth Mana ger retrives the
user information for OpenID " https://proﬁles.google.com/rasib ". The API
server then responds with the user information for Dashboar d/Django-Nova
to allow the user to log in into the interface.
<?xml version="1.0" ?>
<OpenidAuthVerifyResponse xmlns="http://ec2.amazonaw s.com/doc/nova/">
<requestId>C5J4N394A9-TI8Y5BD4O</requestId>
<username>rasib</username>
<secretkey>ad68e65d-5599-47ee-b191-8803c57f24b3</se cretkey>
<accesskey>a7caceb8-3b25-435a-a836-d4ce632f450f</ac cesskey>
<file/>
<openid>https://profiles.google.com/rasib</openid>
</OpenidAuthVerifyResponse>

Appendix B
Applicability of OAuth in
OpenStack
OAuth [11] is an open-source platform for authorization del egation between
web services. OAuth enables a user-centric sharing and acce ss of resources
between two service points.
We performed an initial analysis on the applicability of OAu th on OpenStack.
The following sections present a high level implementation design for a
possible use case of OAuth in OpenStack.
B.1 OAuth Overview
OAuth performs allows authorization delegation on behalf o n the user,
between to service points. OAuth speciﬁcations [11] provid es the following
sequence of operations to implement authorization with OAu th:
1. User-X is at ServerA, and wants to access a remote resource from
ServerB.
2. ServerA sends sends a request to ServerB for a " request_token " to the
request_token_URL in ServerB.
3. ServerB responds with a " request_token " to ServerA.
4. ServerA redirects User-X with the " request_token " to the authoriza-
tion_URL in ServerB to authorize the remote resource.
84

APPENDIX B. APPLICABILITY OF OAUTH IN OPENSTACK 85
5. User-X authenticates and authorizes the resource for Ser verA at
ServerB.
6. ServerB redirects User-X back to ServerA with the authori zed
"request_token ".
7. ServerA uses the authorized " request_token " to send a request to the
access_token_URL in ServerB for an " access_token ".
8. ServerB responds with an " access_token ".
9. ServerA then uses the " access_token " to send requests to the re-
source_URL in ServerB to access the remote resource which the user
has authorized.
B.2 Use Case
An overview of a use case for OAuth in OpenStack is shown in ﬁgu re B.1.
Figure B.1: OAuth Use Case Overview
User-X is assumed to own two accounts with two separate OpenStack
providers. OpenStack providers A and B are assumed to pre-sh are a service
level agreement. There can be two use cases in this scenario.
B.2.1 Use Case 1
User-X Requests Resource from OpenStack Provider B through
OpenStack-Provider A

APPENDIX B. APPLICABILITY OF OAUTH IN OPENSTACK 86
User-X is at OpenStack provider A. However, the user wishes t o request a
resource from OpenStack provider B, through provider A.
Thus, the remote resource request is implemented using OAut h between
OpenStack providers A and B. Provider A redirects User-X to p rovider B.
At provider B, the user authorizes some resources for provid ers A. User-X is
then again redirected to provider A, and delegates the OAuth authorization
token.
Provider A then accesses the authorized resource on provide r B with the
OAuth token.
B.2.2 Use Case 2
User-X Pre-Authorizes Resources on OpenStack Provider B fo r
OpenStack-Provider A
User-X is at OpenStack provider A. The user then conﬁgures a c loud
scaling feature on provider A, such that provider A can dynam ically scale
the resources from User-X’s account on OpenStack provider A to User-X’s
account on OpenStack provider B.
During conﬁguration, provider A redirects User-X to provid er B. The user
then presets authorized resources for provider A for a certa in duration. User-
X is then redirected back to provider A with an OAuth authoriz ation token
for the speciﬁed duration.
Provider A saves the OAuth token for User-X, and can use the to ken to
dynamically scale up the resources to provider B, till when t he token expires.
B.3 Signalling Sequence Overview
In our future work, we aim to implement OAuth in OpenStack for delegated
authentication. We have designed the initial signalling se quence of OAuth
in OpenStack, shown in ﬁgure B.2, to implement the use cases d escribed in
section B.2 on page 85.
The user initially submits the remote OpenStack Provider’s URL to access
a remote resource. The front-end server on Provider-A thus c alls the
"RemoteResource " API in the back-end OpenStack server.
Provider-A then calls the " DescribeURL " API in Provider-B, to discover
theauthorization_URL in Provider-B. Provider-B thus responds with the

APPENDIX B. APPLICABILITY OF OAUTH IN OPENSTACK 87
Remote
Resource URLAPI:RemResAPI:DescURL
DescURLResponse
Save(URLs)API:ReqToken
ReqTokenResponseRemResResponse
Parse XML HTTP 302 Redirect
Auth_URL
Authenticate/Authorize ResourceHTTP 302 Redirect
Callback_URLAPI:ShowServ
Save
(AuthReqToken)API:AccessToken
AccessTokenResponse
Save
(AccessToken)
ShowServResponse
Parse XMLShow Services
Remote
Resource ReqAPI:RemResReq
Retrieve
(AccessToken)OpenStack Provider A
GUI
ServerUser
OpenStack Provider B
API:RemReq
RemReqResponse
RemResReq
Response
Figure B.2: OAuth in OpenStack Signalling Sequence
authorization_URL in the XML object, which Provider-A saves, and starts
the second phase of operation.
Provider-A then calls the " RequestToken " API in Provider-B. Provider-B
thus responds with a " request_token " to Provider-A. Provider-A’s back-

APPENDIX B. APPLICABILITY OF OAUTH IN OPENSTACK 88
end then sends the " RemoteResourceResponse " XML, with the token, and
the required redirectional parameters to the front-end GUI server. The
front-end thus parses the XML object, and redirects the User -Agent to the
authorization_URL in Provider-B.
The user then authenticates and authorizes the resource on P rovider-B. After
that, Provider-B redirects the User-Agent back to the front -end GUI server
of Provider-A at the pre-conﬁgured callback_URL , which was included in
the "request_token ".
The callback_URL at the front-end GUI calls the " ShowServices " API in
Provider-A, along with the authorized " request_token ", to display the
list of services authorized from Provider-B. Upon receivin g the request,
the Provider-A back-end saves the token, and calls the " AccessToken " API
in Provider-B with the authorized " request_token ". Provider-B receives
the authorized " request_token ", and responds with an " access_token ".
Provider-A then receives the " access_token ", saves it, and sends an XML
response to the front-end GUI to display the authorized serv ices on Provider-
B.
After this, the user can request a remote resource on the fron t-end
GUI. The front-end in turn calls the " RemoteResourceRequest " API in
Provider-A’s back-end. The back-end receives the request, and retrieves the
"access_token " to call the " RemoteRequest " API in Provider-B. Provider-
B thus receives the request with the valid " access_token ", allocates the
resource, and sends back a success message to Provider-A.
B.4 Summary
Implementation of OAuth in OpenStack will introduce ﬂexibi lity in the
authorization of resources on the platform. It could be used and extended
in various ways. This section provides an overview of OAuth, along with
two applicable use cases for delegated authorization. Furt hermore, we also
presented the initial design for OAuth on OpenStack.

www.kth.seTRITA-ICT-EX-2011:158

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: Degree project in [611922] (ID: 611922)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

Degree project in [611922]

Copyright Notice

Design and parametric analysis of a half toroidal [623866]

Introducere…3 [625514]

Călugărul Simion îș i desemneaz ă urmașul la tron . Dumitru Manolache, A fost călugărit înainte de [606983]

Capitolul 1. APRECIERI GENERALE DESPRE CORUP Ț IE ………..4 Sec ț iunea 1: Corup ț ia- flagel al societă [628779]

Se consideră că această ruptură s-ar datora unei transformări mixomatoase a valvulelor și fragilizării cordajelor, secundară întiderii lor. [311023]

AUTOR:PROF. ȊNV . PRIMAR: BĂLAN S. MIRELA(CIOROIU) [613232]

Copyright Notice

Similar Posts