Skip to content

IAM4NFDI Logo

Virtual Organisations: the Concept#

Whether you lead a research project and need to say who is on your team, or you run a service and need to decide who may use it, you are looking at the same model from two sides. This page covers the model. It is worth spending ten minutes on this model before going to your side of it.

The problem we are actually solving#

Imagine a project that has twenty-five people across six institutions. It uses a GitLab instance, a storage allocation, a JupyterHub, two databases and some compute time. Each of those services keeps its own list of who is allowed in.

Six lists, one team - and the person who actually knows the team, the principal investigator, holds none of them. Every joiner costs six emails. Every leaver costs six more, or, far more commonly, gets forgotten.

The forgetting is the serious part. Joiners complain loudly when their access does not work, so they get fixed. Leavers complain about nothing at all, because their access still works. These lists do not drift randomly; they drift in one direction, towards people who should no longer be there.

The root cause is that the people who know who belongs are not the people who hold the lists.

Delegated group management#

A Virtual Organisation (VO) moves the membership decision to where the knowledge already is.

The PI maintains one structure in one place: in a Community AAI, describing who is on the team and how it is divided up. That structure is carried to every service the team uses, as part of the user’s login. The service stops asking “is this person on my list?” and starts asking “is this person in the group I was told to trust?” - a question it does not have to maintain the answer to.

On the words "VO" and "Community"

The team is usually not an organisation in any legal sense: its members in our example are employed by six different universities, and no single directory contains all of them. It is virtual in that no HR department has heard of it, and an organisation in that it has members and makes decisions.

The term “Virtual Organisation” comes from the grid computing era. Today you may more often hear Community for the same idea - which is why the systems are called Community AAIs and the people running them Community Managers. Treat VO and Community as interchangeable; this documentation says VO because that is what NFDI says.

How membership and allocation work together#

Access is never produced by one thing alone. It appears where two separate pieces meet:

who is on the team (the group, maintained by the PI) + what has been granted (the allocation, held by the provider) = access

Each half is looked after by whoever is actually in a position to know it. The PI knows the team; only the provider knows what it has approved and for how long. Neither has to learn the other’s half, and that is the whole trick - the two are kept apart precisely so they can be combined freely.

That also means a change to one half does not disturb the other. The PI adds and removes people without renegotiating the grant; the provider extends or reduces the grant without being sent a new list of names.

  • The Group - an AAI concept

    • Lives in a Community AAI
    • Expresses who belongs to a team
    • Governed by the community’s membership policy
    • Known to the AAI? Yes - as AARC-G069 entitlements
    • Managed by the VO admin

  • The Project / Allocation - a business concept

    • Lives in a service, or an infrastructure’s allocation system
    • Expresses what was approved, to whom, for how long
    • Governed by the provider’s approval process
    • Known to the AAI? No
    • Managed by the service provider

Neither half works alone

Being in a group is not access. The link between a group and an approved allocation is what produces it, and that link is held by the service, not by the AAI. A VO whose PI has not applied for anything is a perfectly valid VO that, however, opens no doors at all - and an allocation with no group attached has nobody who can use it.

Separating the grant from the membership list is not new. Applying for compute time has long worked this way, and so have instrument time and licensed datasets: the proposal gets you an allocation, and the project attached to it has members who may spend it. What the VO concept adds is portability - the membership half is maintained once, and every service provider that honours the group sees the same answer.

Who does what#

The AAI states facts; the service makes judgements. Keeping these apart buys something concrete: a service can change its access policy without asking the AAI for anything.

What a group membership looks like#

Group memberships travel to services as entitlements: strings in a standard syntax, sent with every login. One membership is one string:

urn:geant:dfn.de:nfdi.de:nfdi4cake:group:cakemaster:data:curators:role=manager#aai.example.de
└────────── namespace ───────────┘ └lit┘ └─ grp ──┘ └ subgroups ┘ └── role ──┘ └ authority ─┘
└───── chosen by the AAI operator ──────┘└─────── chosen by community ───────┘ └ technical ─┘

Read from the left, it says: this statement comes from the nfdi4cake community, it is about a group, and the group is curators, inside data, inside cakemaster. The trailing role=manager and #aai.example.de are refinements; both are taken apart in the service admin guide.

That is all a service receives, and all it needs. It does not get a list of your members, or your organisation chart - just, for the person currently logging in, which groups they are in. The format is AARC-G069, so the same string means the same thing at every service that honours it.

There is a second kind, if a service needs it

Some services cannot work with teams at all - their permission model is fixed, or they are software nobody can modify. For those, the AAI can send a resource capability instead: rather than “this person is on the cakemaster team”, it says “this person may read dataset 42”, with the decision already taken further upstream.

It is the exception, not the rule, and neither audience has to decide anything about it here. If it turns out to be relevant, the practical version is in the VO admin guide and the full treatment in the service admin guide.

The life of a VO, in five steps#

To make this concrete, here is one VO from beginning to everyday running. The example is cakemaster: a research project with a principal investigator, a handful of members, and two providers it needs resources from. Watch what the PI has to do at each step, and what they do not.

Step 1 - the team forms. The PI creates the cakemaster group in the consortium’s Community AAI, adds four members, and decides who else may join. At this point the group grants access to precisely nothing. That is not a misconfiguration; it is the normal starting state.

Step 2 - resources are requested. The PI needs compute from one provider and repository space at another. The compute provider requires a formal, reviewed application; the repository grants space automatically under a standing policy for the discipline. Two very different processes, the same outcome: a grant, recorded at the provider, linked to the cakemaster group. Nothing about the group changed - the PI nominated the group that already existed.

Step 3 - a member logs in. She authenticates as usual with her university account. Her membership of cakemaster travels with the login, the service matches it against its own configuration, finds the linked allocation, and lets her in. She was never registered with that provider, and nobody there had to be told her name in advance.

Step 4 - someone joins. A new postdoc arrives. The PI adds him to the group, once, in the place the team already works. No email to the compute provider, no ticket at the repository. At his first login he is admitted to both.

Step 5 - someone leaves. A member moves to another institution. The PI removes her from the group, once. Her access to both providers ends - without the PI contacting either of them, and without anyone at either provider having to remember that she was ever there.

Steps 4 and 5 are the point of the whole arrangement. The PI maintains one list, and both providers stay correct.

The order is not prescribed

These five steps are a narrative, not a required sequence. Plenty of VOs are created long before anyone applies for anything, and plenty of teams apply first and populate the group once the work is certain - some providers will even accept a group that is still empty.

The only firm requirement is that the group is identified when the allocation is attached to it, and kept up to date from then on. Membership may change freely for the project’s whole lifetime.

What you get out of it#

If you lead a project: Manage your team in one place instead of six; changes take effect everywhere without you contacting anybody; you can delegate branches to work-package leads; leavers actually leave; your structure outlives any single service, so changing a provider does not strand it; and you apply for resources as a team, which is how funders already think of you.

If you run a service: you are out of the user-administration business, which was never information you could verify anyway; you authorise on a claim rather than a list, so one line of configuration admits a twenty-five-person team and keeps doing so correctly; allocations become group-shaped, so a quota or shared directory attaches to a group; onboarding a collaboration is a configuration change; and deprovisioning becomes the job of the one person with both the knowledge and the incentive to do it right.

For both: an audit story, since grants are recorded in a system designed to record them; a policy story, because the NFDI policy framework attaches to this model; and reach beyond NFDI. The architecture and the guidelines cited throughout come from the AARC project as the Blueprint Architecture. NFDI builds on it, and so does EOSC, for which NFDI is the German national node. That shared foundation is why a group managed here is understood elsewhere.

Vocabulary#

Virtual Organisation (VO)
People collaborating across institutional boundaries, managed as a unit. Called a Community in most international contexts. In NFDI a consortium is normally the community, with VOs and subgroups representing its internal structure. Casually, “VO” and “group” are interchanged; strictly the VO is the top-level group.
Group / subgroup
A named set of people, arranged in a tree. Membership in a subgroup implies membership in all its ancestors - specified behaviour, not a convention.
Role
A standing held within a group (role=manager, role=chair): the same people, distinguished by what they may do.
Entitlement
The string carrying an authorisation statement. It is the carrier, not the statement - it may express a group membership (AARC-G069) or a resource capability (AARC-G027), distinguished by the literal group or res.
Community AAI
Where a community manages its members, groups and attributes. NFDI offers four implementations; each consortium settles on one.
Infrastructure proxy
Sits below the Community AAIs so a service can be reached by users from several communities without integrating with each separately. See the architecture.
Assurance
How thoroughly an identity is verified and its credentials managed, per the REFEDS Assurance Framework. Services may require a minimum level in addition to group membership. See assurance.
Home IdP
Where the user ultimately authenticates, usually their institution. See Home IdP requirements.

Where to go next#

  • You lead a project or a team

    How to design a group structure, name it so you do not regret it, and keep it current.

    Guide for VO Admins

  • You run a service

    How to receive AARC-G069 entitlements, match them correctly, and map them onto what your service already does.

    Guide for Service Admins

Last change: Oct 15, 2026 12:30:32