Resource Allocation Service (RAS)

The distributed and complex nature of a federation of private clouds, and the number of cloud management middleware available in the market makes interoperability a big challenge. Also, the more autonomous the members of the federation are, the larger the federation can be, since less restrictions are imposed on members for joining it. The architecture of Fogbow's RAS broadens the range of compatible IaaS technologies supported by concealing communication with the various services provided by the private underlying cloud into implementations of well-defined interoperability plugins. In fact, the plugin concept plays a major role in the architecture and design of the RAS, allowing for the easy customization of the service's functionality. Not only the communication with the underlying private cloud is defined by plugins, but also key parts of the authentication and authorization of the resource allocation requests received. These AAA plugins ultimately define the functioning of the RAS at each member of the federation, regarding authentication, authorization and auditing capabilities.

AAA plugins

Five AAA plugins need to be configured when deploying Fogbow's RAS: the token generator plugin, the federation identity plugin, the authentication plugin, the authorization plugin, and the federation-to-local mapper plugin.

To issue a request to the RAS, a user needs first to obtain an appropriate access token with the appropriate federation identity provider (FIdP). The access token is a string of bytes that contains authentication information and attributes associated to the user, that can be used to perform authorization. This access token string and other parameters are embedded in the request that is sent to the RAS through its RESTful API. The token generator plugin allows Fogbow's RAS to serve as an intermediate between the user and the FIdP. Users submit their credentials through a secure connection to the RAS, which contacts the FIdP and generates the appropriate access token. Its Java interface is shown below:

public interface TokenGeneratorPlugin {
    public String createTokenValue(Map<String, String> userCredentials);
}

The federation identity plugin provides a way to extract the user attributes that are codified in the access token string contained in a request. It creates a Token object containing all relevant information that is internally needed by the RAS. Its Java interface is shown below:

public interface FederationIdentityPlugin<T extends FederationUserToken> {
    public T getFederationUserToken(String tokenValue);
}

The federation user token created by the FederationIdentityPlugin using the access token string passed as parameter in the REST call can then be used to authenticate and authorize the user. Authentication is performed by the authentication plugin, whose Java interface is shown below:

public interface AuthenticationPlugin {
    public boolean isAuthentic(FederationUserToken token);
}

Once the authenticity of the federation user token is established, the RAS can invoke the authorization plugin to check whether the attributes associated with the requesting federation user authorizes her/him to perform the operation that she/he is requesting. The authorization plugin needs to implement the following Java interface:

public interface AuthorizationPlugin {
    public boolean isAuthorized(FederationUserToken token, Operation operation, ResourceType type);
}

Finally, before forwarding the request to the underlying cloud, the RAS needs to create a suitable access token that is accepted by the cloud orchestrator. This is done with the help of the federation-to-local mapper plugin. This plugin receives the token object associated to an authentic and authorized federation user, and maps it to a token than can be used in the requests forwarded to the local cloud. This mapping provides the required flexibility that allows each site administrator to autonomously establish, with a fine level of detail, security and allocation policies for federation users. The Java interface of the plugin is shown below:

public interface FederationToLocalMapperPlugin {
    public Token getToken(FederationUserToken token);    
}

Interoperability plugins

These plugins provide a simple way to support multiple cloud orchestrator middleware. They implement six different interfaces required to manage different resources in the underlying cloud. Each of these interfaces are discussed below.

The ComputePlugin, VolumePlugin and NetworkPlugin interfaces provide the methods used to manage resources of the Compute, Volume, and Private Network types, respectively. They have methods to create a resource from an specification contained in a service order, to get the information associated with a resource that has been created, and to delete a resource that is no longer needed. They are shown below:

public interface ComputePlugin {
    public String requestInstance(ComputeOrder order, Token localToken);
    public ComputeInstance getInstance(String instanceId, Token localToken);
    public void deleteInstance(String instanceId, Token localToken);
}

public interface VolumePlugin {
    public String requestInstance(VolumeOrder order, Token localToken);
    public VolumeInstance getInstance(String instanceId, Token localToken);
    public void deleteInstance(String instanceId, Token localToken);
}

public interface NetworkPlugin {
    public String requestInstance(NetworkOrder order, Token localToken);
    public NetworkInstance getInstance(String instanceId, Token localToken);
    public void deleteInstance(String instanceId, Token localToken);
}

The AttachmentPlugin interface provides the methods used to attach a VolumeInstance to a ComputeInstance that have been created on the same site. It provides methods that are similar to the ones of the interoperability plugins previously described (see below).

public interface AttachmentPlugin {
    public String requestInstance(AttachmentOrder order, Token localToken);
    public AttachmentInstance getInstance(String instanceId, Token localToken);
    public void deleteInstance(String instanceId, Token localToken);
}

The QuotaPlugin interface provides the methods used to query the local cloud about the resource quota that has been assigned to the requesting user, as well as what is her/his current allocation. Note that the quota only defines the maximum amount of resources that a user can allocate. Also, depending on how the federation-to-local plugin is configured, this quota may be shared by multiple federation users that are mapped to the same local token. The interface is shown below:

public interface QuotaPlugin {
    public Quota getUserQuota(Token localToken);
}

Finally, the SpecPlugin and the ImagePlugin interfaces provide the methods that allow users to query the local cloud, respectively, about the hardware configurations that are available for the creation of resources, and the software that can be installed in compute resources. The interfaces provide a method to query the identification of all hardware specs/images that can be used by a particular user, and another to query the details of a particular hardware spec/image that is available to the user. The Java interfaces are shown below:

public interface SpecPlugin {
        Map<String, String> getAllSpecs(Token localToken);
        Spec getFlavor(String flavorId, Token localToken);
}

public interface ImagePlugin {
    Map<String, String> getAllImages(Token localToken);
    Image getImage(String imageId, Token localToken);
}