Starting from the scenarios described earlier, but also based on our experience on the topic of credential management in developing cloud-based applications, we describe in what follows a set of functional and non-functional requirements that should be fulfilled by the credential service in order to meet the expectations set forth.
It must be noted up-front that some of these requirements are generic in the sens that they apply to different heterogeneous technologies (in our cases target services), therefore their achievement depends mostly on the nature of the targeted technology. In some situations the requirement can be fully achieved, meanwhile in some other only basic functionality can be provided.
Furthermore we must be aware at all times that although we strive for full control over the credentials, given that the resulting solution will run in a cloud environment, therefore on virtualized systems, perfect security is not achievable. Moreover there must be a balance between security and performance or practicality, therefore implying certain trade-offs in the guarantees that are asked for.
We can not stress enough the fact that in the context of the credential service, the clients we speak about are not "humans" but instead software components or agents which interact with various external services on behalf of the |EU|. These clients are part of the deployed |SPECS| applications, acting on behalf of real persons which are |EU| in the |SPECS| terminology; meanwhile at the opposite end of the spectrum, the target services are other software components or agents part of either the same deployed |SPECS| applications, or most likely services offered as |SaaS| by external |CSP|'s.
|Description:||Implement the relevant part of the chosen target service authentication schemes, namely the one involving the usage of credentials.|
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.
|Description:||Provide support for limiting the usage of certain credentials to a well defined set of clients.|
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.)
|Description:||Allow the concurrent usage of different 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.
|Description:||Provide credentials usage auditing, providing enough information to identify the software component that requested access.|
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.
|Description:||Separate the actual credentials usage from their long term storage, in order to, possibly, prevent or reduce losses and risks in case of successful attacks on any of the credential service components.|
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.)