search

kamax-matrix / mxisd

Federated Matrix Identity Server
GNU Affero General Public License v3.0
220 stars 112 forks source link

Support arbitrary ordered list of Identity stores #57

Closed maxidorius closed 5 years ago

maxidorius commented 6 years ago

Currently, mxisd does not let you add configure the order in which identity stores are used, nor using several instances of an Identity store.

To facilitate failover configurations and/or custom ordering of Identity stores during resolution, it would be ideal that the configuration contains a list of identity stores, identified by their type, and a configuration for each.

Example of possible future configuration:

stores:
  - type: ldap
    config:
       server:
         host: "mainLdapServer"
         ...
  - type: ldap
    config:
      server:
        host: "failoverLdapServer"
  - type: rest
    config:
       ...
  - type: synapseSql
    config:
       ...
maxidorius commented 5 years ago

Closing this issue in favor of a project entry.

mjattiot commented 5 years ago

@maxidorius do you have any plan on implementing "project entry" ? Have you created an issue to follow-up on that matter ?

By the way, thank you for all your great work !

maxidorius commented 5 years ago

@mjattiot Thank you for the kind words!

mxisd was originally designed to connect to an already existing authoritative central Identity source within an network for an org/corp, typically something LDAP based. As time went by, we added more ways to reach data stored in other formats/software, but the original design choice remained that the use case was always a single, central authoritative identity source.

Finally we checked what was the workload to change the initial design choice and actually have a model as described by this issue but came to the conclusion that it couldn't be done without heavily breaking backward compatibility within the v1.x branch and decided to schedule it for v2.x along other fundamental changes.

v2.x is currently hypothetical and there are no timeline or roadmap as it would involve a nearly-full rewrite of the code base. Therefore we closed the issue and removed the milestone until an actual analysis of the workload and roadmap for v2.x was made, if the rewrite takes place.