Clear separation of user and admin documentation.

If the last admin of an organisation delete himself from the organisation, he will have a "Forbiden" red message, but it will still delete his account from the organisation. He will not be able to acces to the organisation anymore.

Deleting the last admin did not change anything for the other users. They can see the organisation in their profile user page and they can still select the organisation to cosume in the applications.

The admin can create a new organisation with the same name but the organisation will not show on the consommation page. If the admin disconnect and reconnect, the new organisation shows in the consommation page with 0% everywhere.

An admin should not be able to delet himself from the organisation if he is the last admin of the organisation. He should not be able to recreate an organisation with the same name.

Configurable.

Come up with a simple material logo.

Do not overkill as brand configuration will replace this logo most of the time, but still we need something.

We had a report of users for whom the link didn't work.

A standard integration, with login link, token receiving and session management.

Ideally no more than a link in UI and a middleware in backend. The middleware should be documentted and available as code (a library ?).

Middleware:

• check presence of temporary token in query param (coming from mail)
• if temp token is present
  • exchange it for an id token with simple-directory and set it in cookie
• check presence of session token in cookie
• if session token is present read it
  • if session token is too old
  • if session token is almost old but still valid
    • exchange it for a new one with simple-directory
    • set the new one in protected cookie
    • set the payload (but not the signature) in unproected cookie for the UI

etc.. this is just a draft. This flow must be analyzed alongside OpenID Connect implementation.

When you join an organization by clicking the accept link in the email, you have to logout ang login to have this organization in your JWT.

Maybe take inspiration from https://github.com/PwdLess/Cierge ?

From the start.

UI, error messages and documentation.

• Google
• Github / Gitlab
• Facebook
• Franceconnect

When creating an account chrome doesn't propose to generate a random password. We must lack some metadata or have another small problem.

For a clean and powerful email templates management we should probably integrate with mjml. This syntax + some documented variable names should do the trick.

We need to decide if we simply use the syntax and library or if we go as far as integrating an editor.

What are the required configuration elements ?

• logo
• title / description for meta
• color scheme

etc.

The main persistence implementation for full functionality.

An admin of an organisation, created before the change of simple directory of may, can't add a new a user in his organisation. The admin can't select any role, if he clicks on add without entering the role, the command will not pass.

Adding a new user to a new organisation works fine. The issue is only with old organisation.

Maintien de la synchronisation des identités

Pour l'instant les infos sont récupérées à la création de compte et c'est tout. Il faut:

• récupérer un refreshToken à la création du compte au travers du fournisseur d'identité
• utiliser ce refreshToken soit à chaque refresh de notre session soit à interval régulier pour vérifier que l'identité distante existe encore et éventuellement récupérer des infos fraiches
• supprimer le lien vers le fournisseur d'identité du compte si l'identité distante n'existe plus

Paramètres pour contrôler un lien plus fort avec les identités distantes

Sur les infos de l'identité distante du compte on peut ajouter quelques éléments. Par exemple:

• grantAccess=orga/dep/role, permet de rendre explicite le fait que cette identité distante est la source de l'appartenance du compte à une orga (le user créé son compte avec un SSO privé et cette connexion lui donne implicitement des permissions)
• principal=boolean, permet de préciser que cette identité distante est la source principale de vérité pour ce compte

Ces éléments sont ajoutés à la création de compte en fonction des paramètres du fournisseur d'identité

Ces informations permettent d'implémenter quelques règles:

• si une identité distante avec grandAccess disparait alors l'appartenance à l'orga disparait aussi
• si une identité distante a principal=true alors les infos du compte issues de cette identité sont en lecture seule dans SD et elles sont récupérées à chaque utilisation du refreshToken
• si une identité distante a principal=true alors le compte ne peut pas avoir de mot de passe local dans SD et ne peut pas se rattacher à d'autres identités distantes sur d'autres fournisseurs

Déclarer un fournisseur d'identité comme principal

Peut se faire soit de manière globale sur l'instance SD soit sur une configuration de site secondaire.

Quand un fournisseur d'identité est principal

• les scénarios de création de compte, login par password, gestion d'orga, etc sont désactivés ou passés en lecture seule selon les cas
• la mire d'authentif redirige immédiatement vers ce fournisseur
• tous les comptes créés ont ce fournisseur marqué comme principal (donc infos en lecture seule, pas de possibilité de password local, etc)

Remarques

On est ici sur des scénarios de fédération avancée d'identité, mais de la fédération quand même (les infos existent en base dans les 2 système et sont synchronisés). Il peut y avoir des scénarios ou les synchronisations ne se font pas en temps réel. Il faut voir quelle garantie on sera capable d'apporter en tenant compte des durées de vie des jetons, etc. À noter que de toute façon avec la persistance de la session côté client dans des jwt, on a déjà de l'asynchronisme là dessus et pas de garantie forte sur la prise en compte instantanée des changements même sans interop avec un fournisseur d'identité.

Je pense que l'intégration keycloak peut être couverte entièrement sous le chapeau oidc sans (ou avec peu de) spécificité, ça signifie quelque chose de plus réutilisable et basé sur un protocole plutôt qu'un interop en dur.

For the GDPR, there should be a button to delete the account and all the data of an user

Simple-directory should help its user manage GDPR obligations.

Possibilities:

• Inventory of applications that contain a user's data
• Inventory of processings
• Webhooks to propagate user deletion
• Manage users' requests for data extraction

etc.

For now all authenticated users have their session stored in long life cookies.

We should allow users to opt-out of this using a "remember me" checkbox.

• checked by default
• no "remember me" for super admin sessions
• no "remember me" for super admin authenticated as another user

This service has users emails, it should provides capabilities to send a newletters to users who suscribed to it.

• check that the option is not selected by default when creating an account (GDPR compliance)
• format newsletter for a pretty rendering
• include instructions to unsubscribe

Add a section on the profile for the user to acces his private data

The user could download his data from this section

In the profile user page, renaming an organisation add "Nicolas Bonnel" as an admin of the organisation.

Renaming an organisation does not change the name of the organisation on the left menu. Even if the user disconnect and reconnect, the name of the organisation in the left menu is not changed.

We can move the actual creation after the validation from a link.

Writing new persistence backends should be easy, and the signature should be pretty stable. Something like: writeUser, writeOrganization, readUser, readOrga, findUser, findOrga, etc.

As mush logic as possible should be put outside of this layer so that it is as small and changeable as possible.

Implementations can be readonly, in this case the service acts as a connector to an existing users base and shuts down all management functionnalities that require writes.

First implementations:

• in-memory: for fast deployment and tests
• mongodb: recommended for production environments with writes
• file (readonly): easy way to dump an existing user base or manage test fixtures

Others might follow based on users needs: ldap, etc.

active, inactive, banned, etc...

Exactly what statuses do we want and with what semantic ? Once implemented this should be documented.

When searching users or organizations, we query the list API endpoint. We should add an option to entities to allow them to not appear in this list.

In the UI we should describe what fields appear in the list (id and name ?) so that the user knows what we allows / forbid to see.

One question remains : what is this option default value : true or false ?

A docker-compose example. The list of all supported environment variables, their default values and explanation.

We could use jekyll, like we did for data-fair.

But I would prefer something closer to our stack. Maybe use nuxt in generate mode ?