Target service authentication schemes support

Obviously the most important requirement is that of implementing the relevant part of the authentication protocol of the chosen target service, namely the one that requires access to the credentials.

However this requirement can not be fulfilled by the credential service alone, but in cooperation with the actual client of the target service, especially since for some target services (like those of |AWS|) the authentication scheme requires as input meta-data uniquely characterizing the request in question.

As stated in the overview, with this requirement a generic one, not clearly indicating a list of target services. However this list will be identified as part of other |SPECS| deliverables and activities, and once that list of target services is finalized, this requirement will actually translate into a couple of requirements, one per target service, stating "support AWS services authentication scheme", or "support OpenNebula services authentication scheme", etc. Therefore in analyzing the achievement of this requirement, each of the resulting concrete requirements must be taken in isolation and not as a whole.

It must also be noted that not all the target services could benefit from the credential service in the same amount. Like we have described in the sections related with security concerns in each of the two possible usage scenarios, the level of sophistication, and therefore the inherent flexibility and security, of various target services varies from almost none (i.e. where the actual credentials are sent in plain with each request), to a token-based level (like in the case of |RackSpace| services), to a per-request signature level (like in the case of |AWS| services). Therefore the level of achievement of each specific requirement will vary in comparison from case to case, depending on the particularities of the target service, and as such being outside the control of the developer.

Access control policies to the credential usage

In addition to eliminating the need for target service clients to get access to the credential data, there should be a way to limit their access to the actual usage of such credentials.

Therefore there should be a way to impose access policies at two levels (desirably, but the second one being optional). The first level, implementable in all cases, would control if a certain client can actually use the credentials for a certain target service. Meanwhile the second level, implementable only in some cases, controls for what purposes should the client be allowed to use the credentials in question.

For example in case of |RackSpace| credentials only first level policies can be applied, given that once a token is generated its usage can not be controlled further (except revoked). Meanwhile for |AWS| credentials the policies could expand not only to the second level, namely the allowed actions, like say creating or destroying a |VM|, or accessing a certain |S3| bucket, but even a third level controlling to which resources should the operations be applied to, like say create an |S3| object, but not be able to delete or overwrite it. (Granted that in the case of |S3| these policies could be directly enforced by the target services themselves, as discussed in the corresponding scenario.)

Multiple credentials for the same target service

Taking into account that one of the interaction models targeted by |SPECS| is that in which a single |SPECS| platform instance plays the role of a shared |PaaS|, by offering the same services to multiple |EU|, thus sharing the same infrastructure and consequently the same software components. It is therefore mandatory to be able to handle multiple credentials for the same target service, one (or perhaps multiple) credentials belonging to an individual |EU| and being delegated to |SPECS| to act on behalf of the |EU|.

As such the same software component, playing the role of target service client, might concurrently interact with the same target service, but on behalf of different |EU|'s, hence the requirement of being able to concurrently access different credentials of the same target service, which the credential service must be able to provide.

However it must be noted that this requirement is as much for the credential service as it is for the clients of the target services, and thus clients of the credential service itself.

Credential usage auditing

Due to the cloud's model of "pay as you go", any interaction with a target service most likely results in costs being incurred on behalf of the |EU| owning the credentials. Moreover most of the actions are irreversible, and no recovery is possible (without possibly interacting directly with the cloud provider support team), like for example removing data from an |S3| bucket or terminating a |VM|.

Therefore in the case of incident management an audit of the usage of the credentials is invaluable, and should contain enough information to pin-point the software component that issued the request (and possibly enough information to track the initial request that triggered the chain of actions).

Like in the case of access control policies, multiple levels of auditing would prove useful, the first one indicating when and by whom certain credentials ware used; the second level indicating which specific operations were authorized. Unfortunately, just like in the access control policies, the ability to achieve these levels depends mostly on the actual authentication scheme in question.

Disjoint credential data management and storage

Because no software is without faults, even the proposed credential service might be the target of (successful) attacks. Therefore in order to mitigate the amount of leaked data it would prove useful to separate the different concerns of credentials handling as follows.

One software component should store the credential data (itself or by delegation to a third component), encrypted without having access to the decryption keys. Another software component should have the decryption keys, and each time credentials are needed, requesting them from the first component that just stores them, using them and afterwards discarding them. (A certain small period of caching is foreseen as a solution to performance issues.)