From 7fa0bf1d927ebfe11c0d06ae41cf86ce21a5e2b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 9 Dec 2020 14:08:39 +0000 Subject: [PATCH 1/7] Introduce ADR MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jörn Friedrich Dreyer --- changelog/unreleased/introduce-adr.md | 5 + docs/adr/0001-introduce-accounts-service.md | 43 +++++++++ ...0002-persist-accounts-using-cs3-storage.md | 29 ++++++ docs/adr/0003-outsource-user-management.md | 91 +++++++++++++++++++ 4 files changed, 168 insertions(+) create mode 100644 changelog/unreleased/introduce-adr.md create mode 100644 docs/adr/0001-introduce-accounts-service.md create mode 100644 docs/adr/0002-persist-accounts-using-cs3-storage.md create mode 100644 docs/adr/0003-outsource-user-management.md diff --git a/changelog/unreleased/introduce-adr.md b/changelog/unreleased/introduce-adr.md new file mode 100644 index 0000000000..30ed9b2ea7 --- /dev/null +++ b/changelog/unreleased/introduce-adr.md @@ -0,0 +1,5 @@ +Enhancement: Introduce ADR + +We will keep track of [Architectual Decision Records using Markdown](https://adr.github.io/madr/) in `/docs/adr`. + +https://github.com/owncloud/ocis/pull/1042 \ No newline at end of file diff --git a/docs/adr/0001-introduce-accounts-service.md b/docs/adr/0001-introduce-accounts-service.md new file mode 100644 index 0000000000..a763845676 --- /dev/null +++ b/docs/adr/0001-introduce-accounts-service.md @@ -0,0 +1,43 @@ +# 1. Introduce an accounts service + +* Status: superseded by [ADR-0003](0003-outsource-user-management.md) +* Deciders: @butonic, @felixboehm, @mbarz, @pmaier1 +* Date: [2020-06-15](https://github.com/owncloud/ocis-accounts/pull/34/commits/2fd05e2b6fe2a47c687bd0c0bc5e1b5c48a585b2) + +Technical Story: [persist accounts](https://github.com/owncloud/ocis-accounts/pull/34) + +## Context and Problem Statement + +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email und username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. + +## Decision Drivers + +* OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. +* Time: we want to build a release candidate asap. +* Firewalls need access to guests, typically via LDAP. +* Not all external LDAPs are writebale for us to provision Guest accounts. +* We see multiple LDAP servers in deployments. Being able to handle them is important and should be coveredy by using OIDC + being able to query multiple LDAP servers. + +## Considered Options + +* Accounts service wraps LDAP +* GLauth wraps accounts service + +## Decision Outcome + +Chosen option: "GLauth wraps accounts service", because we need write access to provision guest accounts and [GLauth](https://github.com/glauth/glauth) currently has no write support. + +### Positive Consequences + +* We can build a self contained user management in the accounts service and can adjust it to our requirements. +* We do not rely on an LDAP server which would only be possible by implementing write support in the LDAP libraries used by GLauth which (hard to estimate effort, when will that be merged upstream). + +### Negative Consequences + +* We need to spend time on implementing user management + +## Pros and Cons of the Options + +### Accounts service wraps LDAP + +* Bad, because not all external LDAPs are writebale for us to provision Guest accounts. \ No newline at end of file diff --git a/docs/adr/0002-persist-accounts-using-cs3-storage.md b/docs/adr/0002-persist-accounts-using-cs3-storage.md new file mode 100644 index 0000000000..13b75b9c53 --- /dev/null +++ b/docs/adr/0002-persist-accounts-using-cs3-storage.md @@ -0,0 +1,29 @@ +# 2. Persist accounts in a CS3 storage + +* Status: accepted +* Deciders: @butonic, @felixboehm +* Date: 2020-08-21 + +Technical Story: [File system based indexing](https://github.com/owncloud/ocis-accounts/pull/92) + +## Context and Problem Statement + +To set up HA or a geo replicated setup we need to persist accounts in a distributed way. Furthermore, the bleve index makes the accounts service stateful, which we wand to avoid for a scale out deployment. + +## Considered Options + +* Look into distributed bleve +* Persist users in a CS3 storage + +## Decision Outcome + +Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo replication and HA. + +### Positive Consequences + +* We can store accounts on the storage using the CS3 API, pushing geo-distribution to the storage layer. +* Backups of users and storage can be implemented without inconsistencies between using snapshots. + +### Negative Consequences + +* We need to spend time on implementing a reverse index based on files, and symlinks. diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md new file mode 100644 index 0000000000..55cea3336c --- /dev/null +++ b/docs/adr/0003-outsource-user-management.md @@ -0,0 +1,91 @@ +# 3. Outsource Usermanagement + +* Status: accepted +* Deciders: @butonic, @mbarz, @kfreitag, @hd, @pmaier1 +* Date: 2020-12-09 + +Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) + +## Context and Problem Statement + +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email und username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. + +## Decision Drivers + +* OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. +* Time: we want to build a release candiddate asap. + +## Considered Options + +* Accounts service wraps LDAP +* GLauth wraps accounts service + +## Decision Outcome + +Chosen option: "Move accounts functionality to GLauth and name it accounts", by moving the existing accounts service file based persistence to glauth and use it as a drop in replacement for an LDAP server. The reverse index and web ui existing in the accounts service will move as well in order to make glauth a standalone, small scale user management with write capabilities. + +### Product summary +- GLauth is a drop in user management for small scale deployments. +- OCIS admins can either use the web ui to manage users in glauth or use existing tools in their IDM. +- We hide the complexity by embedding OpenID Provider, an LDAP server and a user management web ui. + +### Resulting deployment options +- Single binary: admin can manage users, groups and roles using the built in web ui (glauth) +- External LDAP: OCIS admin needs do use existing tool to manage users +- Separate OCIS and LDAP admin: OCIS admin relies on the LDAP admin to manage users + +### Resulting technical implications +- add graphapi to glauth so the ocis web ui can use it to manage users +- make graphapi service to directly talk to an LDAP server so our web ui can use it +- keep the accounts service but embed glauth +- add graph api to the accounts service? + +### Positive Consequences + +* The accounts service (which is our drop in LDAP solution) can be disabled. +* No sync + +### Negative Consequences + +* If users want to store users in their IDM and at the same time guests in a seperate user management we need to implement ldap backends that support more than one LDAP server. + +## Pros and Cons of the Options + +### GLauth wraps accounts service + +Currently, the accounts service is the source of truth and we use it to implement user management. + +* Good, because it solves the problem of storing and looking up an owncloud uuid for a user (and group) +* Good, because we can manage users out of the box +* Good, because we can persist accounts in a CS3 storage provider +* Bad, because it maintains a separate user repository: it needs to either learn or sync users. +* … + +### Move accounts functionality to GLauth and name it accounts + +We should use an existing ldap server and make GLauth a drop in replacement for it. + +* Good, because we can use an existing user repository (an LDAP server), no need to sync or learn users. +* Good, because admins can rely on existing user managemen tools. +* Good, because we would have a clear seperation of concerns: + - users reside in whatever repository, typically an LDAP server + - could be an existing LDAP server or AD + - could be our embeddable drop in glauth server + - we use a service to wrap the LDAP server with other APIs: + - graph API - ODATA based restful api, + - [SCIM](http://www.simplecloud.info/) - designed to manage user identities, supported by some IDPs, + - the current accounts API (which is a protobuf spec following the graph api) + - our account management ui can use the graph api service which can have different backends + - an existing ldap server + - our drop in glauth server (which might serve the graph api itself) + - the cs3 api + a future guest provisioning api + a future cs3 user provisioning api + - all ocis services can use the service registry to look up the accounts service that provides an internal api + - could be the CS3 user provider (and API) + - could be the internal protobuf accounts API + - introduce a new guest provisioning api to CS3 which properly captures our requirement to have them in the user repository + - guests need to be made available to the firewall + - storages like eos that integrate with the os for acl based file permissions need a numeric user and group id +* Good, because we can use the CS3 user proviter with the existing ldap / rest driver. +* Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) +* Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth. +* … From cca8cb4386e2126e82733ccc3c13e132ee01d61d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 9 Dec 2020 15:48:11 +0100 Subject: [PATCH 2/7] Apply suggestions from code review Co-authored-by: Alex Unger <6905948+refs@users.noreply.github.com> --- docs/adr/0002-persist-accounts-using-cs3-storage.md | 4 ++-- docs/adr/0003-outsource-user-management.md | 6 ++---- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/adr/0002-persist-accounts-using-cs3-storage.md b/docs/adr/0002-persist-accounts-using-cs3-storage.md index 13b75b9c53..7433fa1f02 100644 --- a/docs/adr/0002-persist-accounts-using-cs3-storage.md +++ b/docs/adr/0002-persist-accounts-using-cs3-storage.md @@ -8,7 +8,7 @@ Technical Story: [File system based indexing](https://github.com/owncloud/ocis-a ## Context and Problem Statement -To set up HA or a geo replicated setup we need to persist accounts in a distributed way. Furthermore, the bleve index makes the accounts service stateful, which we wand to avoid for a scale out deployment. +To set up High Availability (HA) or a geo-replicated setup we need to persist accounts in a distributed way. Furthermore, the [bleve](https://github.com/blevesearch/bleve) index makes the accounts service stateful, which we want to avoid for a scale out deployment. ## Considered Options @@ -17,7 +17,7 @@ To set up HA or a geo replicated setup we need to persist accounts in a distribu ## Decision Outcome -Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo replication and HA. +Chosen option: "Persist users in a CS3 storage", because we have one service less running and can rely on the filesystem for geo-replication and HA. ### Positive Consequences diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md index 55cea3336c..0e63dd8fd2 100644 --- a/docs/adr/0003-outsource-user-management.md +++ b/docs/adr/0003-outsource-user-management.md @@ -1,4 +1,4 @@ -# 3. Outsource Usermanagement +# 3. Outsource User Management * Status: accepted * Deciders: @butonic, @mbarz, @kfreitag, @hd, @pmaier1 @@ -13,7 +13,7 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass ## Decision Drivers * OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. -* Time: we want to build a release candiddate asap. +* Time: we want to build a release candidate asap. ## Considered Options @@ -59,7 +59,6 @@ Currently, the accounts service is the source of truth and we use it to implemen * Good, because we can manage users out of the box * Good, because we can persist accounts in a CS3 storage provider * Bad, because it maintains a separate user repository: it needs to either learn or sync users. -* … ### Move accounts functionality to GLauth and name it accounts @@ -88,4 +87,3 @@ We should use an existing ldap server and make GLauth a drop in replacement for * Good, because we can use the CS3 user proviter with the existing ldap / rest driver. * Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) * Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth. -* … From 972ef91f570edd35050787eefe5e33dff4503550 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 9 Dec 2020 15:54:29 +0100 Subject: [PATCH 3/7] correct github nicks --- docs/adr/0003-outsource-user-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md index 0e63dd8fd2..c6ac9585c4 100644 --- a/docs/adr/0003-outsource-user-management.md +++ b/docs/adr/0003-outsource-user-management.md @@ -1,7 +1,7 @@ # 3. Outsource User Management * Status: accepted -* Deciders: @butonic, @mbarz, @kfreitag, @hd, @pmaier1 +* Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1 * Date: 2020-12-09 Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) From da525aeb500373467cb12c6eb79b143541164b8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 9 Dec 2020 15:56:29 +0100 Subject: [PATCH 4/7] Oh my god? all the typos ... so embarrassing. Thx @phil-davis Co-authored-by: Phil Davis --- docs/adr/0001-introduce-accounts-service.md | 6 +++--- docs/adr/0003-outsource-user-management.md | 10 +++++----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/adr/0001-introduce-accounts-service.md b/docs/adr/0001-introduce-accounts-service.md index a763845676..7a228c0dd7 100644 --- a/docs/adr/0001-introduce-accounts-service.md +++ b/docs/adr/0001-introduce-accounts-service.md @@ -15,8 +15,8 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass * OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. * Time: we want to build a release candidate asap. * Firewalls need access to guests, typically via LDAP. -* Not all external LDAPs are writebale for us to provision Guest accounts. -* We see multiple LDAP servers in deployments. Being able to handle them is important and should be coveredy by using OIDC + being able to query multiple LDAP servers. +* Not all external LDAPs are writeable for us to provision Guest accounts. +* We see multiple LDAP servers in deployments. Being able to handle them is important and should be covered by using OIDC + being able to query multiple LDAP servers. ## Considered Options @@ -40,4 +40,4 @@ Chosen option: "GLauth wraps accounts service", because we need write access to ### Accounts service wraps LDAP -* Bad, because not all external LDAPs are writebale for us to provision Guest accounts. \ No newline at end of file +* Bad, because not all external LDAPs are writeable for us to provision Guest accounts. diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md index c6ac9585c4..7eb36dc951 100644 --- a/docs/adr/0003-outsource-user-management.md +++ b/docs/adr/0003-outsource-user-management.md @@ -8,7 +8,7 @@ Technical Story: [Skip account-service by talking to CS3 user-api](https://githu ## Context and Problem Statement -To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email und username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email and username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. ## Decision Drivers @@ -31,7 +31,7 @@ Chosen option: "Move accounts functionality to GLauth and name it accounts", by ### Resulting deployment options - Single binary: admin can manage users, groups and roles using the built in web ui (glauth) -- External LDAP: OCIS admin needs do use existing tool to manage users +- External LDAP: OCIS admin needs to use existing tool to manage users - Separate OCIS and LDAP admin: OCIS admin relies on the LDAP admin to manage users ### Resulting technical implications @@ -65,8 +65,8 @@ Currently, the accounts service is the source of truth and we use it to implemen We should use an existing ldap server and make GLauth a drop in replacement for it. * Good, because we can use an existing user repository (an LDAP server), no need to sync or learn users. -* Good, because admins can rely on existing user managemen tools. -* Good, because we would have a clear seperation of concerns: +* Good, because admins can rely on existing user management tools. +* Good, because we would have a clear separation of concerns: - users reside in whatever repository, typically an LDAP server - could be an existing LDAP server or AD - could be our embeddable drop in glauth server @@ -84,6 +84,6 @@ We should use an existing ldap server and make GLauth a drop in replacement for - introduce a new guest provisioning api to CS3 which properly captures our requirement to have them in the user repository - guests need to be made available to the firewall - storages like eos that integrate with the os for acl based file permissions need a numeric user and group id -* Good, because we can use the CS3 user proviter with the existing ldap / rest driver. +* Good, because we can use the CS3 user provider with the existing ldap / rest driver. * Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) * Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth. From f6ac7b78637581f2f4bcfcd4198e0fa2364caac2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Thu, 10 Dec 2020 08:41:53 +0100 Subject: [PATCH 5/7] Apply suggestions from code review Co-authored-by: Benedikt Kulmann --- docs/adr/0001-introduce-accounts-service.md | 8 ++++---- docs/adr/0003-outsource-user-management.md | 14 +++++++------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/adr/0001-introduce-accounts-service.md b/docs/adr/0001-introduce-accounts-service.md index 7a228c0dd7..4fafed2482 100644 --- a/docs/adr/0001-introduce-accounts-service.md +++ b/docs/adr/0001-introduce-accounts-service.md @@ -1,7 +1,7 @@ # 1. Introduce an accounts service * Status: superseded by [ADR-0003](0003-outsource-user-management.md) -* Deciders: @butonic, @felixboehm, @mbarz, @pmaier1 +* Deciders: @butonic, @felixboehm, @micbar, @pmaier1 * Date: [2020-06-15](https://github.com/owncloud/ocis-accounts/pull/34/commits/2fd05e2b6fe2a47c687bd0c0bc5e1b5c48a585b2) Technical Story: [persist accounts](https://github.com/owncloud/ocis-accounts/pull/34) @@ -21,16 +21,16 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass ## Considered Options * Accounts service wraps LDAP -* GLauth wraps accounts service +* [GLAuth](https://github.com/glauth/glauth) wraps accounts service ## Decision Outcome -Chosen option: "GLauth wraps accounts service", because we need write access to provision guest accounts and [GLauth](https://github.com/glauth/glauth) currently has no write support. +Chosen option: "GLAuth wraps accounts service", because we need write access to provision guest accounts and GLAuth currently has no write support. ### Positive Consequences * We can build a self contained user management in the accounts service and can adjust it to our requirements. -* We do not rely on an LDAP server which would only be possible by implementing write support in the LDAP libraries used by GLauth which (hard to estimate effort, when will that be merged upstream). +* We do not rely on an LDAP server which would only be possible by implementing write support in the LDAP libraries used by GLAuth (hard to estimate effort, when will that be merged upstream). ### Negative Consequences diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md index 7eb36dc951..f2a1268ca5 100644 --- a/docs/adr/0003-outsource-user-management.md +++ b/docs/adr/0003-outsource-user-management.md @@ -18,19 +18,19 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass ## Considered Options * Accounts service wraps LDAP -* GLauth wraps accounts service +* [GLauth](https://github.com/glauth/glauth) wraps accounts service ## Decision Outcome -Chosen option: "Move accounts functionality to GLauth and name it accounts", by moving the existing accounts service file based persistence to glauth and use it as a drop in replacement for an LDAP server. The reverse index and web ui existing in the accounts service will move as well in order to make glauth a standalone, small scale user management with write capabilities. +Chosen option: "Move accounts functionality to GLAuth and name it accounts", by moving the existing accounts service file based persistence to GLAuth and use it as a drop in replacement for an LDAP server. The reverse index and web ui existing in the accounts service will move as well in order to make GLAuth a standalone, small scale user management with write capabilities. ### Product summary -- GLauth is a drop in user management for small scale deployments. -- OCIS admins can either use the web ui to manage users in glauth or use existing tools in their IDM. -- We hide the complexity by embedding OpenID Provider, an LDAP server and a user management web ui. +- GLAuth is a drop in user management for small scale deployments that don't rely on an actual LDAP. +- OCIS admins can either use the web ui to manage users in GLAuth or use existing tools in their IDM. +- We hide the complexity by embedding an OpenID Provider, an LDAP server and a user management web ui. ### Resulting deployment options -- Single binary: admin can manage users, groups and roles using the built in web ui (glauth) +- Single binary: admin can manage users, groups and roles using the built in web ui (GLAuth) - External LDAP: OCIS admin needs to use existing tool to manage users - Separate OCIS and LDAP admin: OCIS admin relies on the LDAP admin to manage users @@ -51,7 +51,7 @@ Chosen option: "Move accounts functionality to GLauth and name it accounts", by ## Pros and Cons of the Options -### GLauth wraps accounts service +### GLAuth wraps accounts service Currently, the accounts service is the source of truth and we use it to implement user management. From e864db8a2f8b3a551c3d8929958cb0079ae92a89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Tue, 9 Feb 2021 21:44:22 +0000 Subject: [PATCH 6/7] incorporate feedback MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jörn Friedrich Dreyer --- docs/adr/0001-introduce-accounts-service.md | 4 +- ...0002-persist-accounts-using-cs3-storage.md | 2 +- docs/adr/0003-external-user-management.md | 104 ++++++++++++++++++ docs/adr/0003-outsource-user-management.md | 89 --------------- 4 files changed, 107 insertions(+), 92 deletions(-) create mode 100644 docs/adr/0003-external-user-management.md delete mode 100644 docs/adr/0003-outsource-user-management.md diff --git a/docs/adr/0001-introduce-accounts-service.md b/docs/adr/0001-introduce-accounts-service.md index 4fafed2482..a221d90793 100644 --- a/docs/adr/0001-introduce-accounts-service.md +++ b/docs/adr/0001-introduce-accounts-service.md @@ -1,6 +1,6 @@ # 1. Introduce an accounts service -* Status: superseded by [ADR-0003](0003-outsource-user-management.md) +* Status: superseded by [ADR-0003](0003-external-user-management.md) * Deciders: @butonic, @felixboehm, @micbar, @pmaier1 * Date: [2020-06-15](https://github.com/owncloud/ocis-accounts/pull/34/commits/2fd05e2b6fe2a47c687bd0c0bc5e1b5c48a585b2) @@ -12,7 +12,7 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass ## Decision Drivers -* OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. +* oCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. * Time: we want to build a release candidate asap. * Firewalls need access to guests, typically via LDAP. * Not all external LDAPs are writeable for us to provision Guest accounts. diff --git a/docs/adr/0002-persist-accounts-using-cs3-storage.md b/docs/adr/0002-persist-accounts-using-cs3-storage.md index 7433fa1f02..fc738e69bc 100644 --- a/docs/adr/0002-persist-accounts-using-cs3-storage.md +++ b/docs/adr/0002-persist-accounts-using-cs3-storage.md @@ -8,7 +8,7 @@ Technical Story: [File system based indexing](https://github.com/owncloud/ocis-a ## Context and Problem Statement -To set up High Availability (HA) or a geo-replicated setup we need to persist accounts in a distributed way. Furthermore, the [bleve](https://github.com/blevesearch/bleve) index makes the accounts service stateful, which we want to avoid for a scale out deployment. +To set up High Availability (HA) or a geo-replicated setup we need to persist accounts in a distributed way. To efficiently query the accounts by email or username, and not only by id, they need to be indexed. Unfortunately, the [bleve](https://github.com/blevesearch/bleve) index we currently store locally on disk cannot be shared by multiple instances, preventing a scale out deployment. ## Considered Options diff --git a/docs/adr/0003-external-user-management.md b/docs/adr/0003-external-user-management.md new file mode 100644 index 0000000000..1cbc9fbd42 --- /dev/null +++ b/docs/adr/0003-external-user-management.md @@ -0,0 +1,104 @@ +# 3. Use external User Management + +* Status: accepted +* Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1 +* Date: 2020-12-09 + +Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) + +## Context and Problem Statement + +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email and username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. + +## Decision Drivers + +* oCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. +* Time: we want to build a release candidate asap. +* oCIS should be able to be easily integrated with standard user management components + +## Considered Options + +* Accounts service wraps LDAP +* [GLAuth](https://github.com/glauth/glauth) wraps accounts service + +## Decision Outcome + +Chosen option: "Move accounts functionality to GLAuth and name it accounts", by moving the existing accounts service file based persistence to GLAuth and use it as a drop in replacement for an LDAP server. The reverse index and web UI existing in the accounts service will move as well in order to make GLAuth a standalone, small scale user management with write capabilities. + +### Product summary +- GLAuth is a drop in user management for small scale deployments that do not rely on an actual LDAP server. +- oCIS admins can either use the web UI to manage users in GLAuth or use existing tools in their IDM. +- We hide the complexity by embedding an OpenID Provider, an LDAP server and a user management web UI. + +### Resulting deployment options +- Use internal user management + - Recommended for small scale use cases and simple deployments + - Users, groups and roles are stored and managed within GLAuth +- Use external user management + - Recommended for mid and large scale use cases + - Users, groups and roles are stored and managed within an external LDAP/AD directory / IDM + - Separate oCIS and LDAP admin: oCIS admin relies on the LDAP admin to manage users +- User permissions for roles are always managed in oCIS (settings service) because they are specific to oCIS + +### Resulting technical implications +- Make the file based reverse index a standalone library +- Contribute to GLAuth + - Add ms graph based rest API to manage users groups and roles (the LDAP lib is currently readonly) + - Add web UI to glauth that uses the ms graph based rest API to manage users + - Add a backend that uses the file based reverse index, currently living in the oCIS accounts service + - Move fallback mechanism from ocis/glauth service to upstream GLAuth to support multiple LDAP servers + - Make it a chain to support more than two LDAP servers + - Document the implications for merging result sets when searching for recipients + - At least one writeable backend is needed to support creating guest accounts +- Make all services currently using the accounts service talk to the CS3 userprovider +- To support multiple LDAP servers we need to move the fallback mechanism in ocis/glauth service to upstream GLAuth +- The current CS3 API for user management should be enriched with pagination, field mask and a query language as needed +- properly register an [auxiliary LDAP schema that adds an ownCloudUUID attribute to users and groups](https://github.com/owncloud/ocis/blob/c8668e8cb171860c70fec29e5ae945bca44f1fb7/deployments/examples/cs3_users_ocis/config/ldap/ldif/10_owncloud_schema.ldif) + +### Positive Consequences + +* The accounts service (which is our drop in LDAP solution) can be dropped. The CS3 userprovider service becomes the only service dealing with users. +* No sync + +### Negative Consequences + +* If users want to store users in their IDM and at the same time guests in a seperate user management we need to implement GLAuth backends that support more than one LDAP server. + +## Pros and Cons of the Options + +### GLAuth wraps accounts service + +Currently, the accounts service is the source of truth and we use it to implement user management. + +* Good, because it solves the problem of storing and looking up an owncloud UUID for a user (and group) +* Good, because we can manage users out of the box +* Good, because we can persist accounts in a CS3 storage provider +* Bad, because it maintains a separate user repository: it needs to either learn or sync users. + +### Move accounts functionality to GLAuth and name it accounts + +We should use an existing LDAP server and make GLAuth a drop in replacement for it. + +* Good, because we can use an existing user repository (an LDAP server), no need to sync or learn users. +* Good, because admins can rely on existing user management tools. +* Good, because we would have a clear separation of concerns: + - users reside in whatever repository, typically an LDAP server + - could be an existing LDAP server or AD + - could be our embeddable drop in glauth server + - we use a service to wrap the LDAP server with other APIs: + - ms graph API - ODATA based restful API, + - [SCIM](http://www.simplecloud.info/) - designed to manage user identities, supported by some IDPs, + - the current accounts API (which is a protobuf spec following the ms graph API) + - our account management UI can use the ms graph based API service which can have different backends + - an existing LDAP server + - our drop in glauth server (which might serve the ms graph based API itself) + - the CS3 API + a future guest provisioning API + a future CS3 user provisioning API (or [generic space provisioning](https://github.com/cs3org/cs3apis/pull/95)) + - all oCIS services can use the service registry to look up the accounts service that provides an internal API + - could be the CS3 user provider (and API) + - could be the internal protobuf accounts API + - introduce a new guest provisioning API to CS3 which properly captures our requirement to have them in the user repository + - guests need to be made available to the firewall + - storages like EOS that integrate with the os for acl based file permissions need a numeric user and group id +* Good, because we can use the CS3 user provider with the existing LDAP / rest driver. +* Bad, because oCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) +* Bad, because oCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLAuth. diff --git a/docs/adr/0003-outsource-user-management.md b/docs/adr/0003-outsource-user-management.md deleted file mode 100644 index f2a1268ca5..0000000000 --- a/docs/adr/0003-outsource-user-management.md +++ /dev/null @@ -1,89 +0,0 @@ -# 3. Outsource User Management - -* Status: accepted -* Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1 -* Date: 2020-12-09 - -Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) - -## Context and Problem Statement - -To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email and username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. - -## Decision Drivers - -* OCIS should be a single binary that can run out of the box without external dependencies like an LDAP server. -* Time: we want to build a release candidate asap. - -## Considered Options - -* Accounts service wraps LDAP -* [GLauth](https://github.com/glauth/glauth) wraps accounts service - -## Decision Outcome - -Chosen option: "Move accounts functionality to GLAuth and name it accounts", by moving the existing accounts service file based persistence to GLAuth and use it as a drop in replacement for an LDAP server. The reverse index and web ui existing in the accounts service will move as well in order to make GLAuth a standalone, small scale user management with write capabilities. - -### Product summary -- GLAuth is a drop in user management for small scale deployments that don't rely on an actual LDAP. -- OCIS admins can either use the web ui to manage users in GLAuth or use existing tools in their IDM. -- We hide the complexity by embedding an OpenID Provider, an LDAP server and a user management web ui. - -### Resulting deployment options -- Single binary: admin can manage users, groups and roles using the built in web ui (GLAuth) -- External LDAP: OCIS admin needs to use existing tool to manage users -- Separate OCIS and LDAP admin: OCIS admin relies on the LDAP admin to manage users - -### Resulting technical implications -- add graphapi to glauth so the ocis web ui can use it to manage users -- make graphapi service to directly talk to an LDAP server so our web ui can use it -- keep the accounts service but embed glauth -- add graph api to the accounts service? - -### Positive Consequences - -* The accounts service (which is our drop in LDAP solution) can be disabled. -* No sync - -### Negative Consequences - -* If users want to store users in their IDM and at the same time guests in a seperate user management we need to implement ldap backends that support more than one LDAP server. - -## Pros and Cons of the Options - -### GLAuth wraps accounts service - -Currently, the accounts service is the source of truth and we use it to implement user management. - -* Good, because it solves the problem of storing and looking up an owncloud uuid for a user (and group) -* Good, because we can manage users out of the box -* Good, because we can persist accounts in a CS3 storage provider -* Bad, because it maintains a separate user repository: it needs to either learn or sync users. - -### Move accounts functionality to GLauth and name it accounts - -We should use an existing ldap server and make GLauth a drop in replacement for it. - -* Good, because we can use an existing user repository (an LDAP server), no need to sync or learn users. -* Good, because admins can rely on existing user management tools. -* Good, because we would have a clear separation of concerns: - - users reside in whatever repository, typically an LDAP server - - could be an existing LDAP server or AD - - could be our embeddable drop in glauth server - - we use a service to wrap the LDAP server with other APIs: - - graph API - ODATA based restful api, - - [SCIM](http://www.simplecloud.info/) - designed to manage user identities, supported by some IDPs, - - the current accounts API (which is a protobuf spec following the graph api) - - our account management ui can use the graph api service which can have different backends - - an existing ldap server - - our drop in glauth server (which might serve the graph api itself) - - the cs3 api + a future guest provisioning api + a future cs3 user provisioning api - - all ocis services can use the service registry to look up the accounts service that provides an internal api - - could be the CS3 user provider (and API) - - could be the internal protobuf accounts API - - introduce a new guest provisioning api to CS3 which properly captures our requirement to have them in the user repository - - guests need to be made available to the firewall - - storages like eos that integrate with the os for acl based file permissions need a numeric user and group id -* Good, because we can use the CS3 user provider with the existing ldap / rest driver. -* Bad, because OCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.) -* Bad, because OCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLauth. From 1ddfb7c6c50d368765d8d0a498850c3956e34221 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Wed, 10 Feb 2021 13:12:50 +0100 Subject: [PATCH 7/7] Apply suggestions from code review Co-authored-by: Benedikt Kulmann --- docs/adr/0001-introduce-accounts-service.md | 2 +- docs/adr/0003-external-user-management.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/adr/0001-introduce-accounts-service.md b/docs/adr/0001-introduce-accounts-service.md index a221d90793..9e6bf18de8 100644 --- a/docs/adr/0001-introduce-accounts-service.md +++ b/docs/adr/0001-introduce-accounts-service.md @@ -8,7 +8,7 @@ Technical Story: [persist accounts](https://github.com/owncloud/ocis-accounts/pu ## Context and Problem Statement -To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email und username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email und username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party (RP) such as ownCloud should behave, it still requires the RP to maintain its own user identifiers. ## Decision Drivers diff --git a/docs/adr/0003-external-user-management.md b/docs/adr/0003-external-user-management.md index 1cbc9fbd42..68538cccb2 100644 --- a/docs/adr/0003-external-user-management.md +++ b/docs/adr/0003-external-user-management.md @@ -8,7 +8,7 @@ Technical Story: [Skip account-service by talking to CS3 user-api](https://githu ## Context and Problem Statement -To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email and username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party such as ownCloud should should behave, it still requires the RP to maintain its own user identifiers. +To attach metadata like shares to users ownCloud relies on persistent, non-reassignable, unique identifiers for users (and files). Email and username can change when a user changes his name. But even the OIDC sub+iss combination may change when the IdP changes. While there is [an account porting protocol](https://openid.net/specs/openid-connect-account-porting-1_0.html) that describes how a relying party (RP) such as ownCloud should behave, it still requires the RP to maintain its own user identifiers. ## Decision Drivers @@ -36,14 +36,14 @@ Chosen option: "Move accounts functionality to GLAuth and name it accounts", by - Users, groups and roles are stored and managed within GLAuth - Use external user management - Recommended for mid and large scale use cases - - Users, groups and roles are stored and managed within an external LDAP/AD directory / IDM + - Users, groups and roles are stored and managed within an external LDAP / AD / IDM - Separate oCIS and LDAP admin: oCIS admin relies on the LDAP admin to manage users - User permissions for roles are always managed in oCIS (settings service) because they are specific to oCIS ### Resulting technical implications - Make the file based reverse index a standalone library - Contribute to GLAuth - - Add ms graph based rest API to manage users groups and roles (the LDAP lib is currently readonly) + - Add ms graph based rest API to manage users, groups and roles (the LDAP lib is currently readonly) - Add web UI to glauth that uses the ms graph based rest API to manage users - Add a backend that uses the file based reverse index, currently living in the oCIS accounts service - Move fallback mechanism from ocis/glauth service to upstream GLAuth to support multiple LDAP servers