Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

As part of the requirements analysis for the integration of federated identity management systems into OpenStack-based IaaS offerings, we would like various stakeholders to describe what they would like to achieve. The original proposal for the workshop summarised this part as:

Describe an utopia where access of researchers to science clouds is managed perfectly across organisations. This includes onboarding, accounting, cost sharing, lifecycle management etc.

The suggested way to frame these requirements/desiderata is in the form of user stories.

Feel free to add stories of your own!

SWITCHengines perspective (Background)

Onboarding an individual user


Renata is a researcher at the University of X. She would like to try out a shiny new piece of software that her peers have been talking about recently. The tool would (barely) fit on her laptop, but it would be nice to have it run uninterrupted for several days, so a server would be better. Her officemate had told her about SWITCHengines, so she wants to give that a try. But it’s 6PM and she never registered for SWITCHengines. She heads over to and finds a button called “SWITCHaai login”. Since she had used SWITCHaai before to access the school’s learning management system, she gives it a try. After agreeing to send SWITCHengines a few pieces of information about her, such as e-mail address, affiliation and status, she is logged in to the service. She has a modest default quota which, unbeknownst to her, has been configured by her university’s central IT service when the university subscribed to the service. But it is enough to get her started, she logs in using her usual SSH key (uploading the public key to SWITCHengines was easy), and fifteen minutes later she has the shiny piece of software running in a shiny new VM and starts investigating what it can do.


Delegated Subtenant Management

Terminology notice: a “subtenant” roughly corresponds to an OpenStack (Keystone) Project (these used to be called “Tenant”). In the SWITCHengines model, the “real” tenants in the business sense are the academic institutions.




  • No labels