Study: Identity Management

Goal (in few lines)

Compare the different options to manage identities in our Software solutions.

Current Situation

At the moment, Identity Management relies on a set of heterogenous components:

OpenLDAP as the user repository. It could manage groups too but is not administrated for such a use case.
LemonLDAP is the SSO solution, configured since summer 2020 as an OIDc provider (but was used before as an interceptor medium).
The Twake Console is a component developed from fall 2020 to centralize users and companies for our solutions. Primarily named SaaS portal, it now aims at managing companies, users and their profiles.

Roughly, OpenLDAP is where users are stored. LemonLDAP relies on OpenLDAP to authenticate users. And the Twake Console relies on OpenLDAP and its own database (MongoDB) to store user information.

There have been no real design about a global solution.
Everything was built and chosen progressively, hence leading to some inconsistencies. The Twake Console was initiated in summer 2020, following a meeting that took place 6 months before. Development was started before a panorama of existing solutions was done.

Anyway, Software teams reached some kind of consensus about how all of this could work and be completed to handle a global identity management. It does not mean all the use cases are covered and that everything is clear.

Onboarding

The Twake Console provides a portal for users to sign up.
The user is then created in OpenLDAP (for authentication purpose) and then into MongoDB (to store the user profile).

Once registered, a user can sign in by using LemonLDAP and access solutions that are registered in the OIDC provider (e.g. Twake, LinShare, etc). On the first sign in, the application may need to create things for this user. It can be a space in LinShare, a mail box in James, etc.

In this case, the applications’ back-ends will…

… either query the OIDC provider to get user information and provision a local user.
… or query the Twake Console to get user information and provision a local user.

Application front-ends should rely on web services from the Twake Console to retrieve user information (e.g. name, avatar, user language…). It means a part of the Twake Console back-end is a common service that all the front-ends should query.

User Permissions and Preferences

It has been decided that all the users preferences, related to the profile, would remain in the Twake Console. For user preferences related to a given application, they will be managed by the application itself.

It means that a user not only exists in the Twake Console database, but also in all the application he uses. Said differently, users appear in different databases. And their application preferences are stored in the application itself.

The same applies for user permissions.
What they can do or not in an application is stored in the application. It is not centralized.

What can be centralized in the management of the permissions.
We can give the feeling to users everything is centralized, even if under the hood, things are not. That can be achieved by a common management web interface. As an example, it could have one page to manage all the preferences for LinShare. And this page could interact with the web administration services of LinShare. The same applies to all the applications.

It means applications can keep on having the same web interfaces than today: we just add another one that centralize everything. It is the benefit of using REST web services. It also implies there must be a technical account that allows this new console to interact with different back-ends.

To succeed on this path, all the solutions should document their permission system, so that the central administration’s web console can be designed. Some controls in the user interface could even invoke several back-end solutions.

How about groups?

Right now, the Twake Console only manages users and companies, not groups.
There are different strategies: either groups are also handled in all our solutions, or user permissions are inferred by taking group permissions into account.

First solution: Twake Console knows about groups and so do applications. When we provision a new account (e.g. in James), we also provision his groups if they do not exists. The problem is that nothing guarantees all the solution will manage groups correctly or in a coherent policy.
Second solution: Twake Console knows about groups but not applications. When we provision a new account (e.g. in James), the solution asks the user permissions to the Twake Console, which computes them (e.g. quotas). This option has the benefit of computing permissions the same way for all the solutions since it is always done by the same component (Twake Console).
Third solutions: Twake Console does not know about groups but applications do. Groups are locally managed, per solution, in the global administration front-end. Some application groups may have the same name. It is then up to the user interface to give the feeling everything is the same.

Groups raise big concerns.
As an example, for the Calendar, group invitation can result in very low performances. This has not been studied seriously and requires a deeper analysis.

How about changes in user profiles or groups?

It all depends on the way groups and user profiles are defined.
For front-ends (e.g. avatar change), a system of web socket or server-side event is enough. For other changes (e.g. a woman got married and wants to change her family name), there should be a mechanism to push the changes in all the solutions. A pub/sub system can be used, but it introduces coupling between the solutions. Changes performed on a profile in the Twake Console could be propagated to applications through REST API. It would rely on existing mechanisms and avoid a new Software dependency.

For changes performed in the global administration console, changes would directly be pushed from the front-end to the right back-end (Twake, LinShare, James…).

User governance?

Right now, LINAGORA considers moving a user from one company to another, or from one group to another, like a simple operation. However, in some companies, this could require a specific workflow (e.g. follow a business/validation process).

Since such a use case has not been planned, we will not discuss it here.
But notice it is the kind of requirement the Directory Manager (part of LinID) has to cover (based on OpenLDAP).

Again, there is no clear view about the use cases we want to cover.

How about when a user leaves?

With this solution, when a user leaves, we only have to remove him from OpenLDAP.
He cannot authenticate anymore, but all his data and accounts still exist in the other databases.

There are different answers depending on whether we are in a SaaS deployment or on-premise (RGPD law). In any case, since LINAGORA’s business is about companies, the data’s owner is the company and not the user. It means user data in applications (such as e-mails in James, messages in Twake, files in LinShare…) do not need to be deleted. The only thing that MIGHT be deleted are user information and avatar in the Twake Console. Obiously, there may be in applications purge mechanisms (e.g. to save some space, but that’s another thing).

How about when a companies leave?

Then we should remove all the application data (in batch mode) and only then, delete all the accounts and the company from the Twake Console. Notice there may be legal reasons to keep some data. That needs to be studied with the legal team at LINAGORA.

Obviously, there are many situations and it would require a full and real study, based on scenarios, to imagine all the possibilities. This page gives an overview about how it is expected to work.

Notice that there had been brainstorming meetings in the past to discuss about the entities to manage and how to structure them. See this cryptpad. You can require access to Michel-Marie Maudet if necessary.

Methodology and Criteria

Not defined yet.

Solutions to Compare

These solutions could challenge our current stack:

Study

For later.