Cloud issues addressed

Security forms an important part of the Contrail Cloud infrastructure. This is partly to address existing general security concerns in distributed collaborations, such as for a resource provider: "how do I know who my users are", or for a user: "how do I protect my data against being modified/stolen", or concerns specific to the Cloud, such as "how do I know where my data is" and "how do I know I can trust the provider?". Most commonly a user's identity has to be known to the resource provider in a way it allows him to determine whether to grant access to resources or not. In a federated Cloud, each resource provider can have his own set of identity checking rules and tools. That rather complicates things.

Contrail's Solution

Contrail security consists of two parts: the first is a federation which binds together users and resources. The federation part, in general, allows users to log in both via a portal and using command line tools. Users have a single login to the federation, normally using an existing identity, but it can also be a password managed within the federation. Once logged in, they have access to resources from multiple providers with a single identity, and their accounting data is aggregated at the federation level.

The second part of Contrail security consists of evaluations of the levels of protection of data inside the Cloud in a way which is meaningful not just to users but also to services that are looking for resources on behalf of the user. In other words, the protection must be understood by both humans and machines. One common example is restrictions on the geographic region in which the data is stored, but it could extend to higher levels of protection which also worry about how data is transferred and processed. By expressing the security levels within SLAs, we enable a marketplace of Cloud security, where a provider offering more secure processing of data can cover the extra costs associated with implementing this security. More secure services will simply be slightly more expensive, and users who do not worry about their data security can just look for the cheapest provider.

The aim of Contrail Security (ConSec) is to provide a means for users to use external identities to authenticate to service providers: any acceptable external identity can be used to identify users to any internal service managed by the federation.
 
The user thus gets single sign-on: an identity used for other purposes can be used with any federation resource, and, depending on the timing and technology used, he will only need to log in once. 

The advantage for the federation operator is that they do not need to worry about allocating (and resetting) user passwords and keeping account records up to date.  Finally, the resource provider gets at least an extra level of assurance, that authentication data used by the user for other resources is less likely to be shared with other users, and may even be subject to federation policies.

One thing is solving problems for Contrail, another thing is to provide reusable and sustainable code which solves problems for others as well.  Like many other parts of Contrail, ConSec aims to be modular, so components can be replaced, left out, reused, upgraded, etc.  Indeed, ideally ConSec would provide a framework which enables any e-infrastructure provider to make use of federated (i.e., external) identity management.  Whenever possible, ConSec itself is built out of standard components using standard protocols.

In practice, multiple technologies are combined to solve problems.  The user's initial interaction with the service is via a portal, and authentication is usually web-based, using either OpenID or SAML SSO, such as Shibboleth. 

Within the federation, everything is SOA, and REST web services are used.  In order to carry authorisation information with the HTTP headers, we use OAuth2 to delegate the rights to access federation-level services on behalf of users. 

The portal will then typically choose to create an X.509 certificate which it manages on behalf of the user: this is because the OAuth2 access token carries little information, because services are not in general web services based; because not all services can validate an access token; and because we need more fine grained authorisation data. 

The users generally never see the certificate, but it is used to access services on their behalf, and the embedded authorisation assertion is used to check the access control via a standard XACML framework.  Contrail  moreover has implemented an extension to the PDP, called UCON in the diagram (for "usage control") which can re-evaluate an access control decision when the values of attributes change. 

If the decision also changes, the PEP is notified of the change, and can suspend or terminate cloud activities.  This is useful for "volatile" attributes, such as reputation and the remaining funds in prepaid accounts

More information

• Documentation: federated-identity.pptx 
• Developers on OW2: http://contrail.projects.ow2.org/