I. Introduction

Deployment of cloud-based applications are increasing on a large scale (Figure 1) and applications like healthcare (Thota, Sundarasekar, Manogaran, Varatharajan, & Priyan, 2018; Tang, Hu, & Hsu, 2010; Doukas, Pliakas, & Maglogiannis, 2010; Hoang & Chen, 2010; Nkosi & Mekuria, 2010); online education (Chen, Liu, Han, & Xu, 2010; Hong-qing & Yan-jie, 2010; Li (2010); mobile commerce (Alizadeh & Hassan, 2013; Yesudas, Gupta, & Ramamurthy, 2014; Yang, Pan, & Shen, 2010; online gaming and video streaming (Alizadeh & Hassan, 2013); has already gained popularity. However, providing data security is one of the major concerns in these applications. Along with the date security, maintaining confidentiality, integrity, availability, and accountability of the data (Xiao & Xiao, 2013) are also challenging tasks for the cloud service providers. Applications transmitting personal information and performing financial transactions are particularly prone to security threats (Alizadeh & Hassan, 2013).

Figure 1
Architecture of cloud and mobile cloud computing
Guo, Liaw, Hsiao, Huang, & Yen, 2012

Open-Source Cloud [OSC] computing solutions become popular to build a private cloud for user-specific demand. Due to cost-effectiveness, medium and small organizations are migrating their existing infrastructures to the Open Source Cloud Platform. Open Source Cloud Platform can provide robust security features to the application. But handling different levels of user authentication can be a challenging task for OSC.

Authentication is a process of verifying the identity of an individual or an object such as a mobile device. The user has to provide its personal credentials which is then compared with the date, saved in the database (Sarvabhatla & Vorugunti, 2015; Ruj, Stojmenovic, & Nayak, 2014). In OSC, providing security and privacy to the user’s authentication is essential (Grzonkowski, Corcoran, & Coughlin, 2011), as user furnish their sensitive information to the cloud. User access is controlled through proper authentication as an organization has different access policies for different users. Some of the challenges of authentication include complexity in providing user credentials, number of handshakes required for verification and delay.

Most of OSC platforms support the traditional text-based (i.e user-name, password) user authentication. The text-based authentication required a strong password for accessing sensitive services, which may be difficult for a user to remember. Furthermore, for accessing multiple services the user needs to authenticate separately with different credentials, which may be a cumbersome task for the users. Token-based authentication provides a solution for the same. For example, a Service Provider [SP] can use token-based authentication to provide multiple services to its user via an open source cloud platform. The SP can use any third-party authentication tools for token generation.

Popular third-party authentication tools are SMAL 2.0 (Cantor, Kemp, Philpott, & Maler, 2005), OpenID (Recordon & Reed, 2006) and OAuth (Hardt, 2012). To access a service user sends a request for a token to the TPA. On receiving the request, TPA issues a token to the valid user. A token allows the user to access multiple services. Depending upon the TPAs, the format of the token and generation procedure can vary. The token is stored in the secure place (e.g cache memory) for future use. Popular applications like Facebook, Twitter, Google+ and GitHub use tokens for user authentication.

In this paper, we discuss the authentication tools used by the OSCs mainly focusing on token-based authentication. Our main aim is to find the numbers of handshaking required for obtaining a token and accessing a service form the service providers. Note that the authentication delay de- pendent on the transmission and propagation delay of the communication media. Thus, the total numbers of handshakes play an important role in the token-based authentication. Moreover, in Mobile Cloud Computing [MCC] environment, the data communication takes place over an unreliable wireless media. Hence, the goal of the authentication system is to reduce the numbers of handshaking, which maintains the security of the system. We also discuss the details of token-based third-party authentication tools, like SAML, OpenID, OAuth. In addition, we present the security vulnerabilities of token-based authentication.

Rest of the paper is organized as follows: In section-2 we present the basic characteristics of tokens; popular third-party authentications are discussed in section-3; in section-4 we discuss the authentications techniques used in OSC platform in details; and security vulnerabilities of token-based authentication are presented in section 5. Finally we conclude our discussion in section 6.

II. Basics of Tokens

Token-based authentication is based on the notion “what you have” that means what type of information a user has to authenticate itself. Basically token consists of data regarding the identity of a particular user. Users can get a token by providing its username/password, which allows them to access an intended resource for a specific time period. During this time period, further authentication is not needed. One more important feature is that tokens are passable. Token-based authentication is best suited, where a single token can be used for granting access to multiple services.

There are several popular token-based authentication protocols (Zwattendorfer & Tauber, 2012; Chiang, Yen, & Chen, 2013; Kang & Zhang, 2010; Hani & Dichter, 2016), as discussed below. Most popular among them are SMAL 2.0 (Cantor et al., 2005); OpenID (Recordon & Reed, 2006; Mainka, Mladenov, Schwenk, & Wich, 2017); and OAuth (Hardt, 2012; Richer & Sanso, 2017). In the following, we listed the basic overview of token generation and its properties:

Token Generation/Regeneration process

This is one of the most important aspects of token-based authentication mechanisms, generally, tokens are generated by using the following three methods:

• Using Pseudo-Random Number: In this method, the trusted server generates some random bits of specific length (Banerjee, Hasan, Rahman, & Chapagain, 2017), using a Random/Pseudo-Random Number Generator [PRNG] (Wichmann & Hill, 1982). Other popular PRNG algorithms are: Middle Square Method (Von-Neumann, 1946/1951); Linear Congruential Generator [LCG] (Lecuyer, 1999); and Cubic Congruential Generator [CCG]. The bits are then transferred to the user using the secure channel and is used as the one-time authentication key. The length of the key is an important parameter to provide security, against brute force attack. Long key implies sufficient randomness and therefore difficult to break, but on the other hand, requires more storage. Cryptographically Secure Pseudo-Random Number Generator [CSPRNG] (Blum & Micali, 1984) is best suited for this purposes. These random numbers are stored as a key for regeneration of the token.

• Using hashing: In this method, a part of the user’s information like username, timestamp, client network address is provided as an input to a pre-defined hashing function to generate the token. Both, by the server and user, can use the same procedure for generating or regenerating the token. A hash function h is chosen such that for an input x and corresponding hash value h(x), it should be difficult to find an input y for which h(y) = h(x).

• Using encrypting: In this method, some parts of the user’s information is taken as input and encrypted by using a pre-defined key, which is known to both the server and the user. Traditional encryption techniques (i.e., AES, triple-DES) can be used for this purposes. Token generation procedure using encryption needs less storage and less indexing for revoking the token. Kerberos (Neuman, Yu, Hartman, & Raeburn, 2005) uses encryption for generating the token.

Token Size and Format

Every TPA tools has its own token size and format, as there is no standard for the same. For example, in OAuth JSON token stores the user id, scope and some other information as required by the application. On the other hand, Kerberos token contains information like client ID, client network address, validity period and a session key.

Token Validity/Session

The validity of token again depends on the TPA. The validity is defined as how long the generated token can be used to access the specified service. The Kerberos token usually has a default validity of about 10 hours. But it can be changed according to the requirement of an application’s security.

Token Exchange

In general, the token is exchanged through existing networks, without any secure channel. This is the main feature of token-based authentication. Merely hijacking a token does not guarantee an unauthorized entry into the system. Most implementations perform encryption on the token, before transmission. For example, in Kerberos both the server and the user uses the private key for the encryption/decryption process.

III. Third Party Authentication

SAML stands for Security Assertion Markup Language SAML 2.0 (Joshi & Lau, 2018), introduced in 2005, is the current version of SAML standard (Cantor et al., 2005). It is an XML based protocol. The three main parties of SAML 2.0 are the user, Identity Provider [IdP] and Service Provider [SP]. A security token, known as assertions, containing user information is passed between the IdP and SP for validating user’s identity. It allows Single Sign-On [SSO] to web applications, thus eliminating problems like password reuse or theft. SAML 2.0 uses HTTP, SMTP, FTP and SOAP protocols and it requires six handshakes for authentication, as shown in Figure 2a. First, for accessing a service, the user sends a request to the corresponding SP; then, the SP generates a SAML request and redirects the browser to IdP; the IdP validates the user by checking its database and sends a SAML response to the user; finally, the browser sends the response back to the SP and upon verifying the response, SP can provide or deny access to the user.

Figure 2
Token based authentication using SAML (a), OpenID 2.0 (b) and OAuth 2.0 (c)

OpenID 2.0 is an open standard managed by OpenID foundation. It allows the user to log in multiple websites without going through their registration process. Several organization issues or accepts OpenID for user authentication, such as Google, Sun, Yahoo, BBC, IBM. Users can create an OpenID, which is an URL or eXtensible Resource Identifier [XRI] assigned by an OpenId provider [OP], later, the user can use it to access websites, known as Relying Party [RP], supporting OpenID authentication; the OP verifies user’s identity and can share user’s personal information (e.g. name, gender, email) with the RP after consulting with the user. The message exchanged in this protocol are shown in Figure 2b. First, to access a service, the user sends a request to the RP; the RP asks for the login credentials, to which the user can forward its OpenID (URL or XRI) for authentication; RP reads the OpenID and initiates an association with the OP; OP responds back to the RP with a key and an association handle message; Then, OP contacts the user for authentication; on receiving and verifying the login credentials, OP redirects the user to the RP with its signed assertion; finally, RP validates the assertion and creates a session for the user.

OAuth 2.0, unlike SAML or OpenID are open standard authorization protocol. Although, they can be used to perform pseudo-authentication. Using OAuth, a resource owner or an end-user can grant limited access to a third party website or an application, referred as OAuth Client [OC], to retrieve its personal data stored in a Resource Server [RS] by using token provided by an OAuth Authorization Server [AS]. The AS assumes that the user trusts OC with its data and allows the OC to access its APIs. OAuth is commonly used in conjunction with an authentication protocol (e.g. OpenID Connect 1.0). Version 2.0 of this protocol was released in 2012 by IETF as RFC 6749 (Hardt, 2012). As shown in Figure 2c, the user trying to access a third party website/application receives an authorization request from OC, which gets redirected to AS; on receiving the request, AS asks for user’s credentials and verifies the authenticity of the user; on successful verification, AS sends an authorization code to the user and gets redirected to the OC; by providing the authorization code, OC gets an access token from the AS; finally, using this token, OC can access user’s personal data from the RS.

X.509 (Bauer, 2012; Kim & Timm, 2014; Arifeen, Siddiqui, Ashraf, & Waheed, 2015) is an ITU-T standard for a Public Key Infrastructure [PKI], describing the format of a digital certificate that associates a subject (user, machine or service) with its public key. X.509 digital certificates are issued by a TTP, called the Certification Authority [CA]. The CA is also responsible for certificate renewal and revocation. A digital certificate contains information such as subject’s name, subject’s public key, a period of validity and a signature, as shown in Figure 3. The subject name field contains the Distinguished Name [DN] of an entity or the owner of subject’s public key. The signature field has three sections: a). all other fields in the certificate; b). a digest encrypted with CA’s private key; and c). the algorithms and parameters used in b. For verifying the certificate, a subject needs to know the public key of the CA, whereby it can decrypt the signature field in the certificate and verify the subject’s public key by comparing with the one certified by the CA. X.509 digital certificates are also used for mutual authentication and SSO.

Figure 3
X.509 Certificate Format

Kerberos, RFC 4120 (Neuman et al., 2005) is an authentication protocol based on secret-key cryptography. A Trusted Third Party [TTP] is used in Kerberos to perform mutual authentication and SSO over an unsecured network (Le, Truong, Van, & Le, 2015; Al-Janabi & Rasheed, 2011; Khandelwal & Kamboj, 2015). It was originally developed by MIT in the 1980s. Kerberos v5 appeared as RFC 1510 in 1993 and was later replaced by RFC 4120 in 2005. Figure 4 shows the entities of Kerberos with AS and TGS as two important components of KDC. The KDC acts as a TTP, responsible for maintaining the secret keys of all clients and services; following the pair of messages are exchanged in the Kerberos protocol, when a client tries to access service from SP.

Figure 4
Basic Kerberos 5 Authentication Protocol

• In (1-2) of Figure 4, the client sends a request in plain text to the AS for a Ticket-Granting Ticket [TGT]; on receiving the request, AS randomly generates a secret key, client/TGS session key (KC-TGS) shared between client and TGS and sends two messages to the client: Message (a) contains the key KC−TGS and is encrypted with the client’s secret key, and message (b) is the TGT, containing client ID, TGS ID, timestamp, TGT lifetime and KC−TGS encrypted with the secret key of TGS.

• In (3-4) of Figure 4, the client retrieves KC−TGS by decrypting the message (a) using its secret key and generates a new message (c), called authenticator, containing client ID and a timestamp; then, it encrypts (c) with key KC−TGS and sends messages (b) and (c) to the TGS. The TGS decrypts the message (b) with its secret key, gets the session key KC −T GS and uses it to decrypt the message (c). TGS compares the client ID and timestamp presents in the messages (b) and (c) and, if they match, TGS randomly generates a client/SP session key (KC−SP) and sends messages (d) and (e) to the client. Message (d) is the client-to-server ticket containing client ID, timestamp, KC−SP and is encrypted with the service’s secret key; message (e), containing KC−SP, is encrypted by key KC−T GS .

• Finally in Figure 4 (5-6), mutual authentication takes place between the client and the SP. Client decrypt (e) using key KC−TGS and creates a new message (f ) containing client ID, timestamp. Then (f ) is encrypted using key KC−SP and messages (d) and (f ) are sent to the SP; the SP decrypts message (d) using its service’s secret key and uses KC−SP for decrypting (f ). The SP ascertain the message integrity by comparing client ID and timestamp values in the two messages; then, SP sends a new message (g) back to the client, encrypted using KC−SP, containing the timestamp from message (f ). The client decrypts (g) using KC−SP and checks for the validity of the timestamp.

IV. Authentication for Open Source Cloud

In the following section, we discuss the authentication procedure of some popular Open Source Cloud [OSC] platforms: CloudStack (2018), OpenStack (2018), OpenNebula (2018) and Eucalyptus (2018). The OSCs offer Infrastructure-as-a-Service [IaaS] in a private cloud environment and is a scalable, flexible and cost-effective alternative to the commercial or public clouds, such as Amazon’s AWS, Salesforce’s Sales Cloud, Google’s App Engine or Microsoft Azure. The security concerns about a public cloud platform are relatively bigger than OSCs (Ristov & Gusev, 2013), because: first, a public cloud is a black-box for the customers and they need to trust the security of the CSP before using their service, instead, the internals of an OSC can be studied, changed and updated according to the requirements of the customers; and secondly, OSC being a private cloud platform reduces the internal and external security risks, which is in contrary to the public clouds.

The traditional username password-based authentication is commonly used in all OSC platforms. For this, generally a frontend and a backend authentication components are installed on separate machines. Users enter their login credentials through the frontend (an online user interface, such as Dashboard in OpenStack), and it is verified by the back-end component (Keystone in OpenStack). In addition, most OSC offers other mechanisms for authenticating its users. Third party authentication, like SAML, OpenID 2.0 and OAuth 2.0 can be used in OSC. Users can also use APIs and plugins of OSC to design their own authentication system. Most OSC, like CloudStack and OpenStack, supports the use of Lightweight Directory Access Protocol [LDAP] for authentication, which is discussed below.

The LDAP is an IETF standard, a client-server based application protocol for accessing and modifying directory services over a TCP/IP network. LDAP is a derivative of X.500 Directory Access Protocol [DAP] and is also known as X.500 lite. An LDAP server maintains a hierarchical structure for entries (objects), called Directory Information Tree [DIT]. Each entry is identified by a Distinguished Name [DN], which is a complete path from the root to the entry in DIT. An LDAP client uses DN to send a request (search, add, delete, modify) to an LDAP server and the LDAP server consults the DIT for DN and responds accordingly. However, an LDAP client must authenticate and should have privileges for accessing services from the LDAP server. LDAP authentication can be performed internally using LDAP bind operation or externally via Kerberos or X.509 certificates. LDAP server can also perform authentication on behalf of a web server or email server by using a Pluggable Authentication Module [PAM].

RFC 4513 describes the modes in which an LDAP client can authenticate and access service from an LDAP server. For authentication, the bind operation (RFC 4511) is used for exchanging information between LDAP client and server. Four types of authentication in LDAP are anonymous, unauthenticated, name/password and SASL authentication. The first three are collectively referred to as simple authentication methods; for anonymous authentication, LDAP client sends a bind request to the LDAP server with no DN or password information, it provides limited access (read-only) to the server. Unauthenticated authentication is similar to anonymous authentication, in this, the LDAP client establishes an anonymous state by presenting DN in the bind operation, which is used for logging; the name/password authentication can establish an authenticated authorization state (Figure 5), however, the method is not secure as the password is sent in clear text. LDAP uses SASL framework [Simple Authentication and Security Layer] (RFC 4422) for secure authentication and data transfer. There are several SASL authentication mechanisms, like DIGEST-MD5, CRAM-MD5, GSS- API, Kerberos v4. A series of server challenge (BindResponse) and client response (BindRequest) messages are exchanged for completing a SASL authentication process. In the following section, we will discuss the different open source cloud’s authentication methods in details.

A. Cloudstack

CloudStack is an open source cloud computing platform, developed by the Apache Software Foundation [ASF], for delivering IaaS in a private, public or hybrid cloud environment. The development of CloudStack was originally initiated by Cloud.com. In 2011, Citrix purchased Cloud.com and released the software completely under GNU General Public License (GPLv3); in 2012, the software was relicensed by Citrix under Apache Software License 2.0 (ASLv2) and it was accepted into the Apache Incubator. The first major release of the CloudStack software (version 4.0.0- incubating) was released towards the end of 2012; the current stable version of CloudStack (2018) is 4.11.0.0, released in January 15, 2018. In this section, we mainly focus on the authentication techniques supported by the CloudStack.

CloudStack provides two native methods for authentication, which is based on username/password and HMAC signature. The authentication and authorization in CloudStack is handled by the Access Control Component [ACC], which is a part of the management server (Sabharwal & Shankar, 2013). Users can submit their login request through CloudStack’s web portal, Command Line Interface [CLI] or through API calls (as shown in Table 1); on receiving the request, ACC authenticates the user and determines the access privileges based on the domain, project and other group information of the user; finally, the ACC issues an authentication token indicating the access privileges granted to the user. ACC also saves this information in a log file.

Table 1
Authentication APIs of CloudStack
(CloudStack, 2018)

The LDAP servers, such as Microsoft Active Directory or ApacheDS, can be used for external authentication. CloudStack provides APIs to connect to an LDAP server, search the LDAP Directory Information Tree (DIT) and fetch user information like first/last name, email, username. For authentication, the user enters the username and password through the CloudStack web interface or CLI. CloudStack searches for the username in the DIT of an LDAP server; if successful, it authenticates the user by initiating a bind operation with the Distinguished Name (DN) and password of the user. CloudStack APIs for LDAP are: listLdapConfigurations, addLdap- Configuration, deleteLdapConfiguration, linkDomainToLdap, listLdapUsers, importLdapUsers and ldapCreateAccount.

B. OpenStack

OpenStack (2018) is an open source cloud platform managed by the OpenStack Foundation and is freely available under Apache License 2.0. It provides IaaS to its users in a public and private cloud environment. The latest version of OpenStack is Queens, released on 30 August 2017. OpenStack has a modular architecture, integrating services from various components through their APIs. The core services of OpenStack includes compute, dashboard, block storage, object storage, identity, network and image services (Ismaeel, Miri, Chourishi, & Dibaj, 2015). The compute service (Nova) is responsible for managing the lifecycle of the virtual machines. The storage requirement for saving unstructured data objects and for running instances are handled by the object (Swift) and block (Cinder) storage, respectively. The identity service (Keystone) manages authentication and authorization. All components of OpenStack interact with each other via the network service (Neutron) and the dashboard (Horizon) is the web interface through which administrators or cloud tenants can interact with OpenStack services.

As discussed above, the authentication and authorization in OpenStack is handled by a central identity service named Keystone, who maintains the list of valid users and services that they can access. OpenStack can integrate various authentication techniques though keystone, like user- name/password based, token-based or can authenticate users through an existing directory service like LDAP. Keystone plugins can be used to perform third-party authentication like OAuth, SAML, OpenID and X.509.

OpenStack APIs can be used to create projects (tenants), users, and roles. A project is the logical grouping of users and a role is the set of rights and privileges. After registration, users can submit their authentication request through dashboard (GUI) or using CLI/API calls. The user credentials for authentication can be passed using the environment variables or via the CLI options, for example, URL of an Identity endpoint can be specified with CLI variable --os-auth-url or by using OS-AUTH-URL environment variable. Keystone can be configured to use authentication methods in various domains.

Keystone supports various token providers for authentication, such as Universally Unique IDentifier [UUID] and Public Key Infrastructure [PKI]. Each token differs in technology, scalability and architectural requirements. For UUID token, users send their credential to the Keystone server; the keystone server validates the user; on successful verification, the server generates and sends a UUID token back to the user; the token is passed along with each subsequent API requests from the user; the keystone server verifies the token and sends an appropriate response to the user. A limitation of UUID token is that it generates heavy traffic load on the Keystone server. The PKI token, introduced in OpenStack since 2013, whereby the Keystone server acts as the Certificate Authority [CA]. It issues a certificate and signs the user token by using its secret key. Each API endpoint, with Keystone’s certificate, revocation list, and signature key, can independently validate the PKI token sent by a user.

Khan, Ylitalo, and Ahmed (2011) integrate OpenStack and OpenId to provide “Authentication as a service” and single-sign-on service to its users; in the proposed algorithm, authentication APIs communicate with the user through the GUI and in the back, authentication procedure happens through a Policy Decision Point [PDP].

OpenNebula

OpenNebula (2018; Ristov & Gusev, 2013; Endo, Goncalves, Kelner, & Sadok, 2010) is a popular open source IaaS cloud platform developed by the OpenNebula Community. It integrates hypervisor (Xen, KVM, VMware), database (SQLite, MySQL), distributed file system (GlusterFS, NFS), image datastore (ceph, LVM, vmfs), virtual networks (Open vSwitch) and external servers (DHCP, LDAP) to build and manage flexible cloud platforms. OpenNebula was originally released in 2008. The current stable version is v5.4.0, released on July 20, 2017. The architecture of OpenNebula has three layers: driver, core and tools. The driver at the bottom, it is responsible for interacting with the underlying operating system to allocate resources for spawning Virtual Machines [VMs], handling storage space and networking; in the middle, the core is the centralized management layer that controls and monitors resources for VMs, virtual networks and storage, and also performs Accounting, Authorization and Authentication [AAA] for the users; the tool layer provides the Command Line Interface [CLI], libvirt APIs and web-based GUI for interaction with OpenNebula and for handling the VMs.

By default, OpenNebula has an internal name/password based authentication and authorization system, in which the credentials entered by the user is verified against those already present in the OpenNebulas database; for managing access privileges, users are classified into four types: namely administrator (admin group), regular user (access most functionality), public user (basic functionality and public interfaces) and service user (service user account). In general, an owner of a resource has the privilege of accessing and managing the same and is able to share its resources by use and/or manage privileges with other users. OpenNebula also supports external authentication, via X.509 or LDAP, for its users. Figure 6 corresponding to an architectural overview of OpenNebula authentication. As shown in the Figure 6, authentication can be performed through CLI, API or Sunstone GUI. OpenNebula’s Sunstone server and corresponding web-based GUI simplify the task of interaction and management of the cloud infrastructure, for both, administrator and user. OpenNebula management operations are performed through the Sunstone server. Following are the authentication mechanisms supported in OpenNebula v4.14.

Figure 6
Overview of OpenNebula
(OpenNebula, 2018)

• Built-in name/password and token authentication: OpenNebula commands oneuser create and oneuser delete are used by the administrator (oneadmin) for adding and deleting user accounts. The user information is stored in a backend database for future user authentication. OpenNebula maintains an internal variable, AUTH DRIVER, to select authentication driver for the user. The default driver, core, is used for handling the name/password or token based internal authentication. Users enter their name and a valid password through the Sunstone portal or CLI/API, and it is validated by consulting the backend database. An authentication token, valid for a certain period of time, can also be used for authentication.

• SSH Authentication: In OpenNebula v4.12, the SSH authentication mechanism is only supported through the CLI interface. It uses the standard SSH RSA key pair to perform authentication. The user can generate the key pair and send the public key to the administrator for creating a new user account in OpenNebula. The login phase requires an OpenNebula username and a token encrypted with user’s private key. The user can generate the login token by using oneuser login command, with a default expiration time of 10 hours.

• X.509 Authentication: OpenNebula also supports X.509 certificates, shown in Figure 3, for user authentication and for creating, updating user accounts. An OpenNebula administrator can create the user ac- count using X.509 certificate, with password same the subject’s distinguished name (DN) present in the certificate. For authentication, the X.509 certificates can either be used in two ways. Firstly, the certificates can be passed through CLI. In this mode, the user executes the login command with username, X.509 certificate and private key as parameters. The command uses the private key of the user to encrypt the text document and generates a login token with a default expiration time of 10 hours. Subsequently, the user sends the token to OpenNebula for authentication. The server uses the public key of the user to retrieve the X.509 certificate from the token and uses it to authenticate the user. Secondly, the X.509 certificates can also be used through Sunstone UI. For this configuration, the administrator needs to deploy an SSL capable http proxy on top of the Sunstone server, as shown in Figure 6. It handles certificate validation, encrypts the credentials using server certificate and sends the token to OpenNebula.

• LDAP Authentication: OpenNebula can be configured to perform external authentication through LDAP. For this, an LDAP authentication add-on is used to connect to an existing LDAP server and authenticate the user using Bind operation, as explained earlier. The addon cannot create or modify user information in the LDAP server but can perform Bind and search operations for users on the server.

• Servers Authentication: This method supports the use of external servers for handling authentication in OpenNebula. OpenNebula ships with Sunstone and EC2 servers for this purpose. The servers authenticate the user before forwarding their request to the OpenNebula daemon. Symmetric-key encryption or x509 certificates can be used to secure the communication between the authentication server and Open- Nebula.

D. Eucalyptus

Eucalyptus (2018) is another popular open-source software platform for building Amazon Web Services [AWS]-compatible private and hybrid clouds. It is released under the GPLv3 license and developed by the Eucalyptus Systems Inc. Its current stable version is v4.4.2, released on August 30, 2017. Its five main components are: Node Controller [NC], Walrus Storage controller [WS3], Cluster Controller [CC], Cloud Controller [CLC] and Storage Controller [SC]. The NC is executed on every node hosting VM instances and controls the life cycle of instances on the node by interacting with the OS, hypervisor and CC simultaneously. The CC is the frontend of a cluster, it is responsible for scheduling the execution of VMs on particular NC, collects information of NCs and sends a report to CLC. The CLC provides the web interface for the users to interact with Eucalyptus. In addition, CLC is also responsible for scheduling resources and performs system accounting. WS3 offers persistent storage for VM images, volume snapshots and user data. Finally, the SC provides the block storage for instances within its cluster.

The Identity and Access Management [IAM] system is used for creating and managing user accounts, assigning roles, setting quotas and defining access policies. Eucalyptus manages access control by associating each user with a single account where the users are associated with Groups with certain access privileges. Accounts are identified by its Unique ID or a unique name. Eucalyptus uses two special identities, namely eucalyptus account and admin account, for the administration purposes. An administrator can create or delete accounts, groups and users, and assign roles through CLI by using commands, like euare-accountcreate, euare-groupcreate, euare-rolecreate and euare-usercreate, available in Euca2ools. Eucalyptus supports different types of user credential for authentication, like X.509 certificate and secret access key. Users can enter their credential through the web interface or CLI, what is verified against the information stored in the local CLC database.

Eucalyptus also supports the integration of LDAP or Active Directory (AD) to import user and group information from these servers, however, Eucalyptus maintains the user-specific information, such as secret access keys, X.509 certificates and policies, in its internal database. The mapping of the user/groups information from an LDAP/AD server to the identity structure of Eucalyptus can be either performed manually or based on object classes in LDAP (RFC 4512). The internal database of Eucalyptus can be enabled for automatic synchronization with the LDAP/AD server or the synchronization can be performed manually by uploading the LDAP/AD Integration Configuration [LIC] file.

V. Security Vulnerabilities of Token-Based Authentication

Token-based authentication is popularly used in lots of applications. Many service providers like Facebook, Twitter, Google+ and GitHub use tokens for user authentication. Although the system has advantages as it eases up the process of authentication, it has the following limitations:

• Firstly, and the most important one, the authentication information of every users is stored in a centralized database (Aull, Kerr, Freeman, & Bellmore, 2003). This database can be a bottleneck in various use-cases. Denial-of-service attack, hacking or any other catastrophic event can bring the whole system to a halt.

• The placement of user data is another important issue, the application developer uses third-party token based authentication tools for this purposes. The sensitive user credentials are stored on the third-party server, which may use the data for their own benefit. For example, one of the largest third-party authentication provider OAuth was found guilty of selling user data (Chaabane, Ding, Dey, Kaafar, & Ross, 2014). Moreover, users are unaware of the information residing inside the token.

• Putting many eggs in one basket (Wright, 1996) is a vital issue for token-based authentication. In general, a single token is used for a number of services on the network, if somehow, an unauthorized person gets access to one service using a forged token, then it can gain access to all the services that entitled to use.

• Furthermore, the third-party mechanisms are subjected to phishing attacks (Garera, Provos, Chew, & Rubin, 2007). These concerns are being actively addressed at different platforms, but a complete solution is not yet available. Whenever an issue arises, the concerned party resolves that issue by issuing updates. One such incident happened with OAuth when a user side script could signing on the system without using any password.

VI. Discussion and Conclusions

We have surveyed the token-based authentication techniques used by the popular open source cloud platforms like: Cloudstack, Open-Stack, Eucalyptus, and OpenNebula. We explore the properties of a token and discuss the third party authentication tools that are commonly used in the OSC platform like SAML, OpenID 2.0 and OAuth 2.0. Also, we extensively studied the number of handshakes required for obtaining tokens and for accessing services form the service providers, and we discuss the security vulnerabilities of token-based authentication. Now, we briefly remark important features, observations and limitations of token-based authentication technique.

Token-based authentication reduces the problem of remembering multiple username and password for accessing different services from a CSP. As a result, it increases the password security and accelerates the signup process (Cirani, Picone, Gonizzi, Veltri, & Ferrari, 2015). However, there are some security vulnerabilities in token-based authentication, such as it is prone to phishing attacks (Hammer-Lahav, 2010). In addition, the user privacy can be misused in token-based authentication. Another disadvantage is that it lacks the anonymity for the user, as the user’s information can be miss-handled or shared by the service provider (Tan, Hsu, & Pinn, 2001).

The most popular token based authentication technique is OAuth. It is used by both, Google and Facebook, for providing their services to the user. It provides API based user authorization framework with well-defined security measures and can be used for supporting long lasting web-based services to the user. However, as the framework of OAuth 2.0 is highly extensible, interoperability of the components can be challenge (Hardt, 2012).

OpenID provides a platform to the users where a user can choose a third-party service provider for its authentication purposes. OpenID uses a discovery protocol to find the provider for a corresponding openID. This is a main difference between OpenID and SAML, with SAML, users are coupled with the SAML Identity Providers, which is not true for OpenID. Nowadays, OpenID based authentication is mostly used in designing the mobile applications.

Kerberos, on the other hand, is designed by MIT for secure mutual authentication between a user and a service provider. It can resist attacks, like phishing, intrusion and replay; however, the specification requires all components (i.e Kerberos server, user and servers) to co-exist in the same network for accessing services from Kerberos, which can be a limitation for accessing to cloud services.

References

Alizadeh, M. & Hassan, W. (2013). Challenges and opportunities of mobile cloud computing. In: Wireless Communications and Mobile Computing Conference (IWCMC), 2013 9th International, (pp. 660-666). IEEE.

Al-Janabi, S. T. F. and s. Rasheed, M. A. (2011). Public-key cryptography enabled Kerberos authentication. In: Developments in E-systems Engineering (DeSE), 2011, (pp. 209-214). IEEE.

Arifeen, F. U., Siddiqui, R. A., Ashraf, S., & Waheed, S. (2015). Inter-cloud authentication through x.509 for defense organization. In: Applied Sciences and Technology (IBCAST), 2015 12th International Bhurban Conference on, (pp. 299-306). IEEE.

Aull, K., Kerr, T., Freeman, W. & Bellmore, M. (2003). US Patent App. 10/027,607 [Public key infrastructure token issuance and binding]. Washington, DC: US Patent and Trademark office.

Banerjee, A., Hasan, M., Rahman, M. A. & Chapagain, R. (2017). Cloak: A stream cipher based encryption protocol for mobile cloud computing. IEEE Access, 5, 17678-17691.

Bauer, C. (2012). X.509 identity certificates with local verification. In: Communications (ICC), 2012 IEEE International Conference on, (pp. 6727-6732). IEEE.

Blum, M. & Micali, S. (1984). How to generate cryptographically strong sequences of pseudorandom bits. SIAM Journal on Computing, 13(4), 850-864.

Cantor, S., Kemp, I. J., Philpott, N. R. & Maler, E. (2005, March). Assertions and protocols for the oasis security assertion markup language [OASIS standard]. Retrieved from: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Chaabane, A., Ding, Y., Dey, R., Kaafar, M. A., & Ross, K. W. (2014). A closer look at third-party OSN applications: Are they leaking your personal information? In: International Conference on Passive and Active Network Measurement, (pp. 235-246). Basel, Swizerland: Springer.

Chen, X., Liu, J., Han, J. & Xu, H. (2010). Primary exploration of mobile learning mode under a cloud computing environment. In: E-Health Net- working, Digital Ecosystems and Technologies (EDT), 2010 International Conference on, (Vol. 2, pp. 484-487. IEEE.

Chiang, J., Yen, E.-W., & Chen, Y.-H. (2013). Authentication, authorization and file synchronization in hybrid cloud: On case of Google Docs, Hadoop and Linux local hosts. In: Biometrics and Security Technologies (IS- BAST), 2013 International Symposium on, (pp. 116-123). IEEE.

Cirani, S., Picone, M., Gonizzi, P., Veltri, L. & Ferrari, G. (2015). IoT-OAS: An OAuth-based authorization service architecture for secure services in IoT scenarios. IEEE Sensors Journal, 15(2), 1224-1234.

Apache CloudStack: Open source cloud computing [Website]. (2018). Retrieved from: http://cloudstack.apache.org/

Doukas, C., Pliakas, T. & Maglogiannis, I. (2010). Mobile healthcare information management utilizing cloud computing and Android OS. In: Engineering in Medicine and Biology Society (EMBC), 2010 Annual International Conference of the IEEE, (pp. 1037-1040). IEEE.

Endo, P. T., Goncalves, G. E., Kelner, J. & Sadok, D. (2010). A survey on open-source cloud computing solutions. In: Brazilian Symposium on Computer Networks and Distributed Systems. SBC-LARC.

Eucalyptus cloud platform. (2018). Retrieved from: https://github.com/eucalyptus/eucalyptus

Garera, S., Provos, N., Chew, M., & Rubin, A. D. (2007). A framework for detection and measurement of phishing attacks. In: Proceedings of the 2007 ACM Workshop on Recurring Malcode, (pp. 1-8). New York, NY: ACM. doi:10.1145/1314389.1314391

Grzonkowski, S., Corcoran, P., & Coughlin, T. (2011). Security analysis of authentication protocols for next-generation mobile and CE cloud services. In: Consumer Electronics - Berlin (ICCE-Berlin), 2011 IEEE International Conference on, (pp. 83-87). IEEE.

Guo, M.-H., Liaw, H.-T., Hsiao, L.-L., Huang, C.-Y., & Yen, C.-T. (2012). Authentication using graphical password in cloud. In: Wireless Personal Multimedia Communications (WPMC), 2012, 15th International Symposium on, (pp. 177-181). IEEE.

Hammer-Lahav, E. (2010). The OAuth 1.0 protocol [IETF technical report]. Retrieved from: https://tools.ietf.org/html/rfc5849

Hani, Q. B. & Dichter, J. P. (2016). Secure and strong mobile cloud authentication. In: 2016 SAI Computing Conference (SAI), (pp. 562–565). IEEE.

Hardt, D. (2012). The OAuth 2.0 authorization framework [IETF proposed standard]. Retrieved from: https://tools.ietf.org/html/rfc6749?

Hoang, D. & Chen, L. (2010). Mobile cloud for assistive healthcare (mocash). In: Services Computing Conference (APSCC), 2010 IEEE Asia-Pacific, (pp. 325-332). IEEE.

Ismaeel, S., Miri, A., Chourishi, D. & Dibaj, S. M. R. (2015). Open source cloud management platforms: A review. In: Cyber Security and Cloud Computing (CSCloud), 2015 IEEE 2nd International Conference on, (pp. 470-475). IEEE.

Joshi, R. & Lau, W. (2018). US Patent 9,973,491 [Determining an identity of a third-party user in an SAML implementation of a web-service]. Washington, DC: US Patent and Trademark office.

Kang, L. & Zhang, X. (2010). Identity-based authentication in cloud storage sharing. In: Multimedia Information Networking and Security (MINES),2010 International Conference on, (pp. 851-855. IEEE.

Khan, R., Ylitalo, J. & Ahmed, A. (2011). OpenID authentication as a service in OpenStack. In: Information Assurance and Security (IAS), 2011, 7th International Conference on, (pp. 372-377). IEEE.

Khandelwal, N. S. & Kamboj, P. (2015). Two factor authentication using visual cryptography and digital envelope in Kerberos. In: Electrical, Electronics, Signals, Communication and Optimization (EESCO), 2015 International Conference on. IEEE. https://doi.org/10.1109/EESCO.2015.7253638

Kim, H. & Timm, S. C. (2014). X.509 authentication and authorization in Fermi Cloud. In: Utility and Cloud Computing (UCC), 2014 IEEE/ACM 7th International Conference on, (pp. 732-737). IEEE.

Le, H. Q., Truong, H. P., Van, H. T. & Le, T. H. (2015). A new pre-authentication protocol in Kerberos 5: Biometric authentication. In: Computing Communication Technologies - Research, Innovation, and Vision for the Future (RIVF), 2015 IEEE RIVF International Conference on, (pp. 157-162). IEEE.

Lecuyer, P. (1999). Tables of linear congruential generators of different sizes and good lattice structure. Mathematics of Computation of the American Mathematical Society, 68(225), 249-260.

Li, J. (2010). Study on the development of mobile learning promoted by cloud computing. In: Information Engineering and Computer Science (ICIECS), 2010 2nd International Conference on, (pp. 1-4). IEEE. https://doi.org/10.1109/ICIECS.2010.5678245

Mainka, C., Mladenov, V., Schwenk, J. & Wich, T. (2017). SoK: Single sign-on security: an evaluation of openID connect. In: Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, (pp. 251-266). IEEE.

Neuman, C., Yu, T., Hartman, S. & Raeburn, K. (2005). RFC 4120: The Kerberos network authentication service (v5) [IETF proposed standard]. Retrieved from: https://tools.ietf.org/html/rfc4120.html

von Neumann, J. (1951). Various techniques used in connection with random digits “Monte Carlo Method”. In: A. S. Householder; G. E. Forsythe; and H. H. Germond (Eds.). National Bureau of Standards Applied Mathematics Series, 12, (pp. 36-38). Washington, D.C.: U.S. Government Printing Office.

Nkosi, M. & Mekuria, F. (2010). Cloud computing for enhanced mobile health applications. In: Cloud Computing Technology and Science (Cloud-Com), 2010 IEEE Second International Conference on, (pp. 629-633). IEEE.

OpenNebula.org [Website]. (2018). Retrieved from: http://opennebula.org/

OpenStack [Website]. (2018). Retrieved from: http://www.openstack.org/

Hong-qing, G. & Yan-jie, Z. (2010). System design of cloud computing based on mobile learning. In: Knowledge Acquisition and Modeling (KAM),2010 3rd International Symposium on, (pp. 239-242). IEEE. https://doi.org/10.1109/KAM.2010.5646248

Recordon, D. & Reed, D. (2006). Openid 2.0: A platform for user-centric identity management. In: Proceedings of the Second ACM workshop on Digital Identity Management, (pp. 11-16). New York, NY: ACM.

Richer, J. & Sanso, A. (2017). OAuth 2 in Action. Shelter Island, NY: Manning Publications.

Ristov, S. & Gusev, M. (2013). Security evaluation of open source clouds. In: EUROCON, 2013 (pp. 73-80). IEEE.

Ruj, S., Stojmenovic, M., & Nayak, A. (2014). Decentralized access control with anonymous authentication of data stored in clouds. Parallel and Distributed Systems, IEEE Transactions on, 25(2), 384-394.

Sabharwal, N. & Shankar, R. (2013). Apache CloudStack cloud computing. Packt Publishing.

Sarvabhatla, M. & Vorugunti, C. (2015). A robust mutual authentication scheme for data security in cloud architecture. In: Communication Systems and Networks (COMSNETS), 2015 7th International Conference on, (pp. 1-6). IEEE.

Tan, W., Hsu, J., & Pinn, F. (2001). US Patent App. 09/792,785 [Method and system for token-based authentication]. Washington, DC: U.S. Patent and Trademark Office.

Tang, W.-T., Hu, C.-M. & Hsu, C.-Y. (2010). A mobile phone based home-care management system on the cloud. In: Biomedical Engineering and Informatics (BMEI), 2010 3rd International Conference on, (Vol. 6, pp. 2442-2445). IEEE.

Thota, C., Sundarasekar, R., Manogaran, G., Varatharajan, R. & Priyan, M. (2018). Centralized fog computing security platform for IoT and cloud in healthcare system. In: Exploring the convergence of big data and the internet of things, (pp. 141-154). IGI Global.

Wichmann, B. A. & Hill, I. D. (1982). Algorithm as 183: An efficient and portable pseudo-random number generator. Journal of the Royal Statistical Society. Series C (Applied Statistics) 31(2): 188-190.

Wright, B. (1996). Eggs in baskets: Distributing the risks of electronic signatures, J. Marshall J. Computer & Info. 15(2), 189. Retrieved from: https://repository.jmls.edu/jitpl/vol15/iss2/1/

Xiao, Z. & Xiao, Y. (2013). Security and privacy in cloud computing. IEEE Communications Surveys & Tutorials, 15(2): 843-859.

Yang, X., Pan, T. & Shen, J. (2010). On 3g mobile e-commerce platform based on cloud computing. In: Ubimedia Computing (U-Media), 2010 3rd IEEE International Conference on, (pp. 198-201). IEEE.

Yesudas, M., Gupta, S., & Ramamurthy, H. (2014). Cloud-based mobile commerce for grocery purchasing in developing countries. IBM Journal of Research and Development 58(5/6): 16:1-16:7.

Zwattendorfer, B. & Tauber, A. (2012). Secure cloud authentication using eIDs. In: Cloud Computing and Intelligent Systems (CCIS), 2012 IEEE 2nd International Conference on, (Vol.1, pp. 397-401). IEEE.

Author notes

Additional information

How to cite: Banerjee, A. & Hasan, M. (2018). Token-Based Authentication Techniques on Open Source Cloud Platforms. Sistemas & Telemática, 16(47), 29-30. https://doi.org/10.18046/syt.v16i47.3211