Cloud Computing Patterns, Mechanisms > Cloud Service and Storage Security Patterns > Cloud Resource Access Control
Cloud Resource Access Control (Cope, Erl)
How can cloud consumer attributes be made available to determine cloud resource access control in multiple proprietary clouds?
Problem
Proprietary cloud providers each have their own methods and protocols for authentication and access control, which contributes to vendor lock-in.
Solution
A cloud single sign-on (SSO) architecture is established, incorporating an authentication gateway service (AGS) and attribute authority for implementation of cloud resource access control.
Application
An AGS and attribute authority connected to a secure token service (STS) are implemented and provisioned with the organization’s cloud consumers’ accounts and attributes. An attributed based access control (ABAC) mode of access control is instituted as the cloud service provider using the organization’s SSO infrastructure.
Mechanisms
Attribute Authority, Attribute-Based Access Control System, Secure Token Service, Single Sign-On
Compound Patterns
Burst In, Burst Out to Private Cloud, Burst Out to Public Cloud, Cloud Authentication, Cloud Balancing, Elastic Environment, Infrastructure-as-a-Service (IaaS), Isolated Trust Boundary, Multitenant Environment, Platform-as-a-Service (PaaS), Private Cloud, Public Cloud, Resilient Environment, Resource Workload Management, Secure Burst Out to Private Cloud/Public Cloud, Software-as-a-Service (SaaS)
Cloud Consumer A is directed to the AGS for authentication (1). The AGS authenticates Cloud Consumer A and requests an attribute token from Organization A’s attribute service (2). Incorporating an STS function, the attribute service issues an attribute token to the AGS for Cloud Consumer A. The attribute token has a short lifespan, typically around 2 to 3 minutes (3). The AGS provides the attribute token to Cloud Consumer A, which supports access control as an SSO model with attributes of the cloud consumer. The attributes will be used by the cloud service providers to determine access privileges (4). Cloud Consumer A provides the attribute token to Service A to prove authentication and support an access decision for its resources. Cloud Consumer A is also required to use their certificate and a holder-of-key (HOK) assertion as part of the attribute exchange protocol with the cloud service. Without an HOK check, the attribute token can be stolen and used by an attacker (5). Using an SSO architecture, the cloud consumer provides the attribute token to Service B to prove authentication and support an access decision for its resources. Again, Cloud Consumer A is required to do an HOK check as part of the attribute exchange protocol (6).
This mechanism is covered in CCP Module 7: Fundamental Cloud Security and
in Module 8: Advanced Cloud Security.
For more information regarding the Cloud Certified Professional (CCP) curriculum, visit www.arcitura.com/ccp.
The architectural model upon which this design pattern is based is further covered in:
Cloud Computing Design Patterns by Thomas Erl, Robert Cope, Amin Naserpour
(ISBN: 9780133858563, Hardcover, ~ 528 pages)
For more information about this book, visit www.arcitura.com/books.