User Tools

Site Tools


User Authentication/authorization

Code SRUM-3
Responsible Leandro Navarro
Components testbed server, testbed node


Users (researchers) should be securely authenticated and authorized so only the proper users are able to perform the actions desired.


User permission management need to create, read, update and delete (CRUD) operations for authentication (tokens) and authorization (permissions).

These operations are strongly linked with the user management requirement, as identity could also relate to the identities on the community networks.

The identity of a user (id/auth-token) can be a simple pair uname/pass, uname/key_pair or even a full-qualified user id (e.g. email-address) and auth token, that can even be federated (e.g. OpenID, OAuth)

We can borrow most of the terminology from PlanetLab if not suggested otherwise.



Researchers need a way to manage the attributes and permissions associated to its unique identity (and its relationship to resource slices).

Researchers are assumed to be registered on the central server beforehand with a unique id (e-mail?). The list of high level management functions they can perform through the main web server interface would be (TODO: look closely to the SFA interface but it is something like that):

  • Add/Delete/Modify users: bind a existing user/researcher to a slice so they have access.
  • Allow/deny/grant permissions: manage permissions (users wrt slices/resources, users to operations)

Nodes might simply need to know the identities of the users allowed to access a specific sliver (or the “root” sliver by the admins) so there must be a way to keep that info up to date at each node involved.

Some users might be allowed extended operations on a node/sliver or on the server based on the level of access required by its experiment, on its skills or needs, on its special role in the testbed, or on the choice of a testbed manager

Open discussions

(as in other requirements)

  1. Need to specify the list of configuration parameters and the exact protocol (e.g. configuration file format) between nodes and confine server.
  2. How this type of data is spread across nodes?
    • Polling the server every now and then (Planetlab polls the configuration every 30 minutes with a random deviation to avoid flash crowds). They use polling because some nodes are behind a NAT/Firewalls and do not allow direct access. Is that our case?
    • Something similar to the sms plugin of bmx would be suitable?

Finding out which are the specific requirements in community networks. E.g. requiring researchers to abide the specific community network agreement (e.g. pico-peering agreement, or achieving some kind of reputation level or a level of resource contribution) before being given a wider range of permissions (e.g. capture packet headers)


Confine is quite similar to Planetlab but over a set of nodes inside community networks.

  • For the server i'd suggest to implement something similar (simpler perhaps) based on PLC (reusing code from PLC is probably overkill).
  • For the nodes: I'd suggest looking at the NodeManager code of PlanetLab as it already supports all these requirements. I'm not saying using the actual code but we may reuse some or get some ideas from there.
  • Federation (open-ID, openAuth) sounds tempting wrt federation and existing community network's IDs, but it should be explored to see cost/benefits.
  • The software development effort in Pangea's control panel might fit into this.
requirements/user-auth.txt · Last modified: 2012/01/30 23:44 by leandro