incorporate feedback

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
2021-02-09 21:44:22 +00:00
parent f6ac7b7863
commit e864db8a2f
4 changed files with 107 additions and 92 deletions
@@ -1,6 +1,6 @@
 # 1. Introduce an accounts service
-* Status: superseded by [ADR-0003](0003-outsource-user-management.md) <!-- optional -->
+* Status: superseded by [ADR-0003](0003-external-user-management.md) <!-- optional -->
 * Deciders: @butonic, @felixboehm, @micbar, @pmaier1 <!-- optional -->
 * Date: [2020-06-15](https://github.com/owncloud/ocis-accounts/pull/34/commits/2fd05e2b6fe2a47c687bd0c0bc5e1b5c48a585b2) <!-- optional -->
@@ -12,7 +12,7 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass
 ## Decision Drivers <!-- optional -->
-* 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.
@@ -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
@@ -0,0 +1,104 @@
 # 3. Use external User Management
 * Status: accepted <!-- optional -->
 * Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1 <!-- optional -->
 * Date: 2020-12-09 <!-- optional -->
 Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) <!-- optional -->
 ## 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 <!-- optional -->
 * 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 <!-- optional -->
 * 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 <!-- optional -->
 * 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 <!-- optional -->
 ### GLAuth wraps accounts service
 Currently, the accounts service is the source of truth and we use it to implement user management. <!-- optional -->
 * 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. <!-- optional -->
 * 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.
@@ -1,89 +0,0 @@
 # 3. Outsource User Management
 * Status: accepted <!-- optional -->
 * Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1 <!-- optional -->
 * Date: 2020-12-09 <!-- optional -->
 Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020) <!-- optional -->
 ## 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 <!-- optional -->
 * 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 <!-- optional -->
 * The accounts service (which is our drop in LDAP solution) can be disabled.
 * No sync
 ### Negative Consequences <!-- optional -->
 * 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 <!-- optional -->
 ### GLAuth wraps accounts service
 Currently, the accounts service is the source of truth and we use it to implement user management. <!-- optional -->
 * 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. <!-- optional -->
 * 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.