Federated Domains

Federating domains consists of having an agreement between the participating organizations that allows resources to be used between their distinct domains. This agreement ensures a certain level of fairness of use between the members and the services offered by the different partners. This section describes the architecture needed to create such a federation, as well as tools and deliverables that are needed.

1. Architecture

The required infrastructure for federating domains is a trust relationship and a security configuration. It is important to have single sign on between the different domains, and to have security assertions of one domain be recognized by the other domains. This usually involves a complex setup between Identity Providers, Security Token Services and Identity Attribute Systems.

Figure 3: Federated Architecture's Security with V-Infrastructures

The IdP used within this project will allow to use both SAMLv2 assertions – typically used in academic contexts -- or the WS-Trust / Cardspace based STS used by industry. An important part of federation is to provide monitoring and control over the resources that are offered. This will ensure that the members of the federation are respecting the terms of service, and the policies and rules of the federation, to ensure a smooth resource exchange between the sites.

2. Tools

In this project, federation will be built using Inocybe V-Infrastructure's federation management website. This seamlessly integrates with any IaaS-based resources. V–Infrastructure can be used free of charge when resources are not traded for a fee; otherwise a percentage of the transaction will be deducted as brokerage fees. V-Infrastructure uses a deployment of the Higgins open source identity framework -- the same technology used by IBM’s Tivoli Federated Identity Manager 6.2 . Users can obtain Managed Information Cards from their respective providers, and each provider can have a provider page to advertise the resources, services, applications and packaged solutions.

Figure 4: V-Infrastructures will be used as the exchange gateway between providers.

As an external contribution to this project, Inocybe will modify V-Infrastructures to show the carbon footprint of the aggregate collection of resources.