Version 8 (modified by, 8 years ago) (diff)


Strategies and Approaches for Federating with GENI

GENI provides a variety of methods by which external resources, systems and testbeds can federate with GENI. By 'federate', we mean to be able to share resources, services or information with GENI in a mutually trusted manner.

There are typically three broad categories of federation with GENI:

  • Identity Federation: Sharing identity information between GENI and another system
  • Control Plane Federation: Allowing GENI users access to your services, or your users access to GENI services
  • Data Plane Federation: Allowing Layer 2 network connection between resources allocated on GENI and resources allocated on your testbed.

This page describes different approaches supported in GENI for these different kinds of federation. The following figure summarizes these different kinds of federation and key approaches:

Figure for Summarizing Approaches for GENI Federation

Identity Federation

Identity Federation is the act of trusting and sharing identity information about users between systems. As described below, other systems can share information about its users with GENI via Identity Provider integration, while GENI shares information about its users through OpenID .

Identity Provider Integration

In order for GENI to authenticate a user, it needs an identity provider to release "Research and Scholarship" (R&S) attributes to GENI. Many academic institutions belong to the InCommon Identity federation and of these, many provide the R&S attributes. Such institutions automatically gain access to GENI. Other systems need to set up an identity provider that provides the appropriate attributes.

If they do, GENI will include their Identity Provider (IdP) in its list of trusted IdP's. GENI in turn will provide its Identity Service Provider (SP) meta-data to your IdP so that your IdP recognizes GENI's SP. From there, a user from an outside institution can create a GENI account using single sign-on authentication to the GENI Portal via their IdP.

A number of systems, e.g. NTUA, Cafe, UPMC, SAVI, Chameleon have shared their identity information with GENI in this manner, allowing them to log into GENI services and use GENI resources.

More information about GENI's approach to Identity Provider Integration can be found at

OpenID Integration

A number of systems or services rely on GENI to provide identity attributes to it: they do not have their own IdP but wish to rely on GENI for identity information.

GENI implements an OpenID Identity Provider. It will share standard identity attributes (e.g. user nickname, email) with services implementing the OpenID Relying Party protocol. Other attributes (e.g project membership) may be provided by GENI on request.

Only users who have already authenticated to the GENI Portal via the GENI or a federated IdP can share their GENI identity attributes via OpenID.

GENI is currently integrated via OpenID with the GENI Experimental Engine (GEE), the NYU WiTest Lab, LabWiki and Rutgers ORBIT Lab.

More information about GENI's approach to OpenID Integration can be found at

Control Plane Federation

GENI provides two Control Plane API's: the Aggregate Manager (AM) API allowing allocation of resources to sliced topologies for authenticated/authorized users, and the Clearinghouse (or Federation) API which creates trusted credentials to support the AM API along with advertisement registry services.

Aggregate Manager

In order to federate a set of resources (racks, e.g.) with GENI, the owner of these resources must implement an Aggregate Manager service that presents these resources and allows allocation of these resources. Once this AM is in place, the AM must trust the GENI clearinghouse by including the GENI Clearinghouse CA certificate in its bundle of trusted roots. Once these steps are completed, GENI users will be able to share your resources through your aggregate manager.

More details about the GENI Aggregate Manager API can be found at and,


Federating with GENI does not require implementing a Clearinghouse nor interacting with the GENI Clearinghouse (Aggregates do not speak to Clearinghouses). That said, the Clearinghouse maintains a registry of recognized and vetted services and having your Aggregate Manager listed in the GENI Clearinghouse Service Registry is a way of publicizing that you are making your Aggregate Manager (and thus your resources) available to GENI users.

More information about the GENI Federation (Clearinghouse) API can be found at

Data Plane Federation

L2 connection AL2S or other GENI L2 Network Provider Stitching AM managing network resource (VLAN allocation and provisioning)

L2 Connectivity

In order to establish L2 connectivity to GENI resources, the federating resources must be connected to a L2 network provider that connects to GENI. AL2S is a prime example, but other regional networks (CENIC, SOX, NOX, e.g.) satisfy this need as well. Connecting to a GENI topology requires allocating the correct VLAN tag associated with the 'last hop' to the resource and provisioning a circuit for that VLAN. This may require manual circuit management and switch configuration. Automating this process is down by implementing support for stitching, described below.


More information about GENI stitching can be found at

Attachments (1)

Download all attachments as: .zip