User Management v2 Roadmap

This page describes the OW2 user management (UM) service, and its roadmap towards a new version for managing the OW2 user accounts. User Management is meant in the sense of AAA management: authentication, authorization and accounting.

UM v1 situation : what currently exists ?
A complete schema of the platform is available. Here are the main items:

  • A main XWiki farm instance, hosting several wikis one of them being . OW2 users register using the existing OW2 Registration Wizard at On_Line_Registration. It is currently an embed of an OW2 home-made PHP script.
  • A MySQL database, containing all OW2 users and entities data. This DB is currently fed by the registration wizard above. Changes to users data are done by OW2 team using phpMyAdmin [sic] (need to add a link to the current SQL data model here)
  • A forge as GFORGE :
  • Another forge system, Tuleap at
  • TWO distinct LDAP directories.
    • LDAP OW2 : contains a single branch ou=users. Basic entries in there are first created by PHP during the last step of the Registration Wizard (login,email). Then complementary attributes and data are sync'd from the MySQL database mentioned above by LSC every 2min
    • LDAP FORGE : contains GFORGE users an groups. This directory is 100% managed by GFORGE.
  • user's account unique identifier is the username (or login). The Registration Wizard also checks if the email already exists which guarantee that two distinct accounts doesn't share the same email address.

UM v2 Goals
The UM v2 service will bring the following improvements:

  • All the accounts will be stored in a centralized database (a LDAP directory), while they're currently scattered in several databases (MySQL and LDAP).
  • A user self registration service. It will replace the existing OW2 Registration Wizard.
  • A complete user self service profile dashboard
  • It will store information not only about the users but also about roles, the organizations and the projects.
  • It will support the concept of user affiliation to an organization. NB: members wishing to be both individual members, and corporate members (via their professional affiliation, typically a researcher like Jean who works at Inria and who also is an individual member) will have to register twice will two different e-mail addresses (this is a legal constraint, not a technical one).
  • In a later stage, the service will also handle information related to the OW2 platform services and to the user roles (who can access which service with which rights).

Milestone FD: FusionDirectory setup (DONE)

  • Génériser l'arbre
  • Rendre l'arbre "conforme" à l'approche à FusionDirectory
  • Pourquoi parler de départements et pas d'organization dans FusionDirectory
  • Comment attribuer un nom à une organisation ?
  • Comment rattacher des users à une organisation ?
  • Clarifier ce qu'on fait avec les attributs invoicing
  • Connexion de FusionDirectory à un LDAP qui contient cet arbre
  • Migrer les données dans ce nouvel LDAP et édition des données en partie avec FusionDirectory et en partie avec PhpLDAPAdmin
  • Etat des lieux de ce qu'on peut faire depuis FusionDirectory à ce moment là avec les entités et ce qu'il nous manque précisément
  • Préparation du dév des plugins de gestion de profils, organisation et projets
  • Formation avancée à FusionDirectory
  • Check éventuel avec Clément / LemonLDAP
  • Formation ACL
  • TODO SL:
    • explorer davantage l'interface FusionDIrectory et la doc
    • regarder les templates (accès SSH via Martin)

Milestone "Basic user registration with self service" (M1)


  • M1-S1: Basic member registration (XWiki + FD webservice)
    • User John Smith creates an account on by filling in a form with his first name, last name, e-mail address
    • Once he has obtained an account, John can become an individual member of OW2
    • To do this, John hits a link, heads to a form
  • M1-S2: Password update (XWiki + FD webservice)
    • John Smith is logged in and he wants to change his password
    • He heads to its profile page from the OW2 home page
    • He accesses a form from which he can update his password
  • M1-S3: Password reminder (XWiki + FD webservice)
    • John Smith has lost his password
    • John hits a "Log-in" link on
    • From there he can hit a link labeled  "Forgot your password?"
    • He enters his e-mail address, gets a password update link from which he can access a form for creating a new password
  • M1-S4: Organization/Individual member registration (TODO)
    • Company XYZ wants to become a corporate member
    • A representative registers as a basic member and logs in
    • The representative is then invited to register his company as a corporate member by filling in a form
    • This form is sent by e-mail to
    • The OW2 MO takes action and notifies the representative

Implementation steps

  • Install LLNG: see which version. LLNG will be used for obtaining a basic user account (first name, last name, e-mail). Check the login creation procedure.
  • Implement or update an XWiki form for becoming a member
    • The filled in form gets stored in wiki
    • The OW2 sysadmin team gets notified of every new registration
    • The OW2 sysadmin team registers new accounts as an individual member in the OW2 LDAP
    • The OW2 sysadmin team notifies the newly registered individuals that their registration has been completed
    • Define the format of the message to be sent by mail
  • Implement or update an XWiki form for corporate member registration


  • Clarify the domains that we need and that we wish from a UX point of view for covering these 3 following functions:
    • login form
    • authentication check
    • personal dashboard
      * Report to LLNG a bug with login containing non ASCII characters
  • Check if the user can choose his/her login while registering
  • Clarifier la procédure de génération ou de choix de login (idéalement choisir)
    * TODO SL: tester auth
    * TODO SL: créer les formulaires XWiki pour enr un user ou org


Almost ready. Still missing PDF generation for IM/CM registration.

Milestone REG: registration (M2)


  • REG-S1: Individual member registration: same as M1-S1 except John can obtain an account and become a member in a single step. OW2 sysadmins do not need to perform any manual action.
  • REG-S2: Password reminder or update: same as M1-S2 and M1-S3 without any manual action from OW2 sysadmins


  • Use the FusionDirectory web service as an API
  • Develop a REST/JSON bridge from XWiki to the API. Individual user or organization registration can be performed by submitting a JSON file to the User Management API directly from XWiki forms.
  • In the future, possibly: standardize the API (the SCIM API is a good candidate, we need to see if it covers the scenarios completely)


To be discussed

Milestone PROF: profile management


  • PROF-S1: registered user can edit his profile via FusionDirectory: update his bio, add a picture etc.

Milestone ORG-PROJ: project and organization management


  • ORG-S1: the OW2 sysadmin team can manage organizations via FusionDirectory (who is the organization's representative, who are the members of this organization, what is the membership type of the organization, etc. to be completed)
  • In the future: users will be able to declare themselves the organization(s) they're affiliated with, and a basic workflow will be set up so that the representative will validate them.


This milestone requires to extend the UM API to project and organization management capabilities. We need to understand if these capabilities can be generic enough to be implemented for generic scenarios by the LLNG team.

Milestone PROJ: project management

This milestone will consist in developing user interfaces for managing projects and organizations: ability to view who belongs to a project, or to an organization, and to edit these relations.

  • PROJ-S1: the OW2 sysadmin team can manage projects via FusionDirectory (who are the project's contributors, who is the project manager)

Notes about UM v2.1

This section contains notes about some improvements we may consider for the next version of the service.

  • if a significant of users have multiple accounts, (one for individual membership, one for corporate membership typically), that may be worth considering creating an Account class so that one Person can be linked to one or several Accounts (Identity versus Account). That might be useful to check if any standard or convention exists for handling this generic situation.

OW2 internal


Some implementations and other tools

How other do?