Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Subauthorities





In general, sub-authorities are a GENI mechanism allowing any authority to (recursively) divide its namespace, and grant permissions to other principals to administer those namespace portions in a controlled way. So far, ProtoGENI makes use of this facility only to allow slice authorities to make Emulab project structure visible in the SA namespace (which in turn allows CMs involved in the slice to make policy decisions based on project membership, if they want to).


Project URNs

Slices associated with a particular Emulab project follow a specific naming convention. Assuming the SA's URN is

then a slice foo would ordinarily be named:

However, if this slice were designated as belonging to the project bar, then the project name would be inserted as an extra level in the URN "authority" hierarchy, appearing like this:

Project URLs

Emulab SAs also offer per-project XMLRPC interfaces, which are essentially the same ordinary (flat) SA API, but the per-project sub-authorities are accessed at different URLs. There is no need for the URL naming scheme to be well-known or consistent, since the top-level SA will advertise all URLs when necessary, but it is documented here for completeness.

If the top-level SA is accessed at

then the sub-SA corresponding to project bar will be found at

User procedure

From the user's perspective, the only difference between using the ordinary flat SA and a per-project SA is that the procedure to obtain a slice credential changes somewhat. (The Flack client is compatible with per-project slice credentials, but doesn't yet have a streamlined mechanism for requesting them. This is under consideration for future work.)

A user can bring up slivers within a per-project slice by following these steps:

  1. Create or join the appropriate project at the Emulab SA. There is currently no way to do this through any GENI interface; the user must log in to the Emulab web site, manage the project from there (e.g. using the "Join Existing Project" option in the "Experimentation" menu), and wait for approval.
  2. Discover the proper sub-SA URL to use. There are two possibilities here:
    • Ask the SA itself which projects and corresponding URLs to use. A Resolve() call on the user URN will yield a list of valid projects, and a URL for each of them. The lookupuser test script can show this information --- invoke is as: -d name
      where name is the user name in question (final component of the user URN).
    • If the user already knows the proper project to use and is familiar with the URL naming convention above, they can simply compute it themselves.
  3. Register a slice with the sub-authority. This must be done with the URL obtained in the previous step, but is otherwise identical to the normal slice registration procedure. For example: -l -n subsatest
    (Note that the slice name must be unique across ALL slices at the SA, not just the slices within the same project. This is a limitation of the current implementation, and not a general restriction.)
  4. If the slice registration was successful, save a copy of the slice credential from the sub-SA: -l -n subsatest > project-slice-credential
  5. From now on, the user can operate with the sub-SA slice credential exactly like any other -- it can be imported into Flack and used to bring up slivers, or it could be passed to the createsliver test script, etc.