From c5861eb75f6cef5f9cdc6924a6dbfaac094f3cb3 Mon Sep 17 00:00:00 2001 From: Ralf Haferkamp Date: Mon, 29 Sep 2025 10:45:36 +0200 Subject: [PATCH] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jörn Friedrich Dreyer Co-authored-by: Michael Barz --- ...ducation-api-for-multitenant-user-provisioning.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/adr/0002-use-education-api-for-multitenant-user-provisioning.md b/docs/adr/0002-use-education-api-for-multitenant-user-provisioning.md index 7acabe9d13..fe942aadc1 100644 --- a/docs/adr/0002-use-education-api-for-multitenant-user-provisioning.md +++ b/docs/adr/0002-use-education-api-for-multitenant-user-provisioning.md @@ -13,11 +13,11 @@ Reference: https://github.com/opencloud-eu/opencloud/issues/877 With the current multi-tenancy implementation, the user-management is mostly external to the OpenCloud instance. Up to [now](../0001-simple-multi-tenancy-using-a-single-opencloud-instance.md) we relied on some external LDAP server providing the users including their tenant assignment. -We'd like multi-tenancy to also work in environments where no such LDAP server is not available. +We'd like multi-tenancy to also work in environments where no such LDAP server is available. ## Decision Drivers -* Mulit-tenancy must work without some existing external (as in not managed by us) LDAP server +* Multi-tenancy must work without some existing external (as in not managed by us) LDAP server * keep the implementation effort low * allow integration with existing (de)provisioning systems @@ -32,12 +32,12 @@ auto-proviosioning code. The auto-provisioning code does currently use the "normal" graph API to create users. That API is not tenant-aware and would need to be significantly changed -to support multi-tenancy. However currently there is not real need to put +to support multi-tenancy. However currently there is no real need to put tenant-awareness into that API (and it would drive us even further a away from compatibility with the MS Graph API). We could also switch away from the Graph API for auto-provisioning and use some direct calls to the underlying LDAP server. -Also using the auto-provisioning feature means that user are only created +Also, using the auto-provisioning feature means that users are only created when they first login. This means it is not possible to share files with users that have not yet logged in. This is a significant limitation. @@ -46,7 +46,7 @@ Also we don't currently have any de-provisioning features implemented. ### Use the existing Eudcation API of the Graph Service We already implemented the Graph Education API in OpenCloud (based on the MS Graph Education API). -This, appart from the somewhat different naming, does already bring most of what is needed +This, apart from the somewhat different naming, does already bring most of what is needed for provisioning users in a multi-tenant environment. The customer would just need to hookup their existing (de)provisioning system to call the @@ -72,5 +72,5 @@ Use the existing Education API of the Graph Service. if the tenant ids in our system match the tenant ids in the customer's identity provider. * For de-provisioning to work we need to implement a way to lookup users by an external ID as that is only unique identfier the customer's system knows for a user. While the MS Graph API - already provides an `externalId` Attribtue we don't currently support that on our APIs. + already provides an `externalId` Attribute we don't currently support that on our APIs.