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.