Univention Bugzilla – Bug 52890
Make the ID-Connector able to replicate one school to more than one school authority
Last modified: 2022-01-06 17:35:18 CET
At a UCS@school customer a scenario was designed, where we initially wanted to use the Cool Solution (CS) "Sync Users to another domain" (https://help.univention.com/t/cool-solution-sync-users-and-groups-into-a-second-domain/12219). The central IDM is to be replicated in an outsourced, second IDM. The background to this is that some information of the customer on the user objects should be replicated. During the configuration of the CS we already noticed 6 errors in its code. Shortly thereafter, Dirk raised the question of whether the ID-Connector + Kelvin API would not be the much better, supported and safer way if the outsourced UCS system for the HPI school cloud connection was represented as a school authority. Over the weekend I thought about it a few times and came to the conclusion: Yes, ID-Connector + Kelvin API fulfill exactly the necessary points, except for one: The ID-Connector can so far only replicate one school to exactly one school authority (see test scenario further down). In the further course of the project we will come to the point, that school authorities will be connected to the central IDM and will also receive users via ID-Connector / Kelvin, which means, tjat that the corresponding schools are maybe already using the HPI school cloud. I have tested in a test environment how the ID connector behaves when I want to replicate a school to several providers: Request: { "mapping": { "HLG": "traeger2", "TSG": "traeger2", "HLG": "traeger1" } } The result is: The ID connector always only keeps one mapping, namely that which is further down in the list: Response: { "mapping": { "HLG": "traeger1", "TSG": "traeger2" } } The customer clearly advocates the use of the ID-Connector instead of the Cool Solution, for reasons already mentioned, but it is necessary that the ID-Connector learns to be able to replicate one school to more than one school authority. We think that this can also be used in other scenarios for other IT services and we would like to discuss this with you.
There are two possibilities which both need a data migration for existing users of the app: 1) keep the mapping but make the right side a list: { "mapping": { "HLG": ["traeger1", "traeger2"], "TSG": ["traeger2"] } } 2) reverse the mapping and also make the right side a list: { "mapping": { "traeger1": ["HLG"], "traeger2": ["HLG", "TSG"] } } The data migration would be trivial in both cases. Technically the app would always internally use the 1st form, as that is what is needed at runtime. But the configuration can still be the 2nd form, as that is easier for the apps users to maintain. The app can convert the 2nd form into the 1st form at runtime for internal use without problems.