mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-04-16 05:17:55 -04:00
incorporate feedback
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
This commit is contained in:
Jörn Friedrich Dreyer
@@ -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
|
||||
|
||||
|
||||
104
docs/adr/0003-external-user-management.md
Normal file
104
docs/adr/0003-external-user-management.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user