Introduction

Overview
Deliverable structure
Relation with other deliverables

Overview

The main focus of the |SPECS| project is application security, mainly IaaS and PaaS, starting from the design phase, throughout development and finally to deployment and execution, taking into account a variety of aspects such as user authentication and authorization, communication channel security, to stored data security. Therefore each of these issues is tackled in a dedicated report, and many also have software implementations. The current report focuses on a class of such issues, namely authentication (and in future versions possibly also authorization) of (software) clients to their corresponding services.

The tackled problem is the most basic one encountered when one wants to consume remote services, namely how to authenticate the requester (the client) to the service provider (the service in our case); and the available options vary on one axis from no authentication to strong cryptographically-based techniques, and from shared-secrets to third-party authenticator.

Moreover there is another aspect that further complicates the problem, namely the flexibility that is offered during development by the various software solutions, ranging from existing software with limited configuration, up to complete access to the source and the possibility to enhance the software. This factor limits what the developer is able to achieve, and what the |SPECS| credential services are able to provide, and in essence it boils down to:

(open) standard compliant solutions -- where the |SPECS| services have to implement a few existing protocols, thus the security is limited by the capabilities of the protocol;
proprietary compliant solutions -- where the |SPECS| services have to deal with a multitude of different protocols, with security prospects similar to the previous case;
|SPECS|-tailored solutions -- which allow the greatest flexibility in terms of design and implementation, which in turn yield a better match with |SPECS| security requirements;

Deliverable structure

Thus the current report gives details about two |SPECS| solutions (plus two evolutions), each tailored for a specific purpose:

security tokens service -- which is a |SPECS|-tailored solution, allowing not only authentication of clients through signed tokens, but also privilege delegation by conveying assertions about the authenticated entity, and revocation of issued authentication tokens;
credential service -- which is the currently available prototype, tailored to handle the credentials needed for |CSP| service interactions, or other standards compliant protocols;

Before moving to each of these sections, we must note that the term "credential" does not refer strictly to a pair of account identifier and password, but also includes other sensitive information such as shared secrets, public / private keys, |X.509| certificates; in essence any kind of data --- used by the services and not part of their usual logic, but instead used to access the infrastructure or other services --- which should be kept safe is considered a credential.

Each of the sections is roughly structured as follows:

Scenarios -- which provides a few examples of the problems and implied solutions that are relevant to each particular module;
State of the art -- giving an overview of the existing solutions and alternatives, discussing their advantages, disadvantages, and appropriateness in the |SPECS| context;
Requirements -- formally summarizing a set of functional and non-functional requirements that each particular module should provide;
Design -- which presents a rough view of the module's (technical) architecture, specifying the main involved components and the communication patterns between them;
Usage -- which gives a few usage scenarios and links to the module's on-line documentation;
Installation -- which lists the steps needed to install the software solution;