Article Preview
TopIntroduction
Cloud-based services are experiencing a rapid development in the last years due to their lower costs and to their improved flexibility and scalability in dynamically growing together with the workload demands. However, as the use of these technologies become widespread, new security requirements and challenges associated with them emerge at a rapid pace.
From the cloud provider point of view, user identification is one of the most critical issues in order to allow the subscribers to access the available services based on their own secure credentials. Furthermore, the account information kept by provider organizations are associated with contains the user’s personal data (gender, address, credit card numbers, etc.) that may become the target of fraud attacks, identity theft, etc. Therefore, each involved cloud provider must guarantee the safety and privacy of such personal information (Svantesson, D., & Clarke, R., 2010), and this may be a problem when the number of users uncontrollably grows.
Most of the currently available cloud service infrastructures support centralized user identification mechanisms based on proprietary solutions including, traditional username/password tuples, one time passwords, tokens and digital signatures, all providing limited flexibility in their authentication systems. This implied the proliferation of different digital identities that have to be used by the same user in order to access the resources made available from different cloud providers.
However, with the recent development of fully distributed cloud architectures, based on the cooperation of multiple federated sites and organizations, a strong paradigm shift from organization-centric to user-centric identity management solution becomes indispensable in order to provide an adequate degree of security also in more complex infrastructures, requiring the interaction between multiple users and service provider entities within the same cloud. Each identity management solution require two logical component entities: unique identifiers together with an authentication procedure based on their use. Clearly, user-centricity in these components implies a greater scalability with an improved flexibility and usability, easily supporting Single-Sign-On (SSO) mechanisms to be used in federated environments, in order to cope with the multiple identities syndrome without registering the same personal identity on any provider they rely on. Furthermore, the users of modern inter-cloud services should be free to choose their own identity provider according to specific security and privacy requirements/policies as well as to their personal trust relationship with the involved organization.
In this scenario, the OpenID standard (Recordon, D., & Reed, D., 2006) for user-centric digital identity, has gained crescent popularity because of its open and decentralized nature, becoming the solution of choice for the implementation of inter-cloud federated authentication. It is able to achieve cross-application and cross-domain SSO (Armando A. et al., 2013) (Kurdi H. et al., 2014) (Tormo G. D., 2014) allowing service providers to delegate the authentication of their users to other identity providers, greatly reducing the maintenance costs associated to the management of user credentials. At the state-of-the-art Google, like Yahoo! provides a federated login solution implemented by using OpenID 2.0, but is migrating to OpenID Connect 1.0 and OAuth 2.0, also supported by MS Azure in its Active Directory implementation as well as from RackSpace and Amazon Cognito. An OpenID-as-a-service solution for OpenStack has been proposed in (R. Khan, J. Ylitalo, and A. Ahmed, 2011). However, it uses only a single cloud organization to scale the OpenID service, which is susceptible to several threats and performance issues.
Despite its wide acceptance in the cloud arena OpenID is essentially a lightweight solution to be used only in the most “trivial” identity management tasks, typically not involving strategic activities. This is because OpenID is not recognized as a trust system, suffers from several usability problems, is known to be highly vulnerable to phishing and other attacks, introduces critical privacy problems, and hence makes it unappealing to become an OpenID end-user or provider (Brands, S., 2007).