You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
12
18
13
-
## Decision Drivers<!-- optional -->
19
+
## Decision Drivers
14
20
15
21
* oCIS should be a single binary that can run out of the box without external dependencies like an LDAP server.
16
22
* Time: we want to build a release candidate asap.
@@ -27,16 +33,16 @@ To attach metadata like shares to users ownCloud relies on persistent, non-reass
27
33
28
34
Chosen option: "GLAuth wraps accounts service", because we need write access to provision guest accounts and GLAuth currently has no write support.
29
35
30
-
### Positive Consequences<!-- optional -->
36
+
### Positive Consequences
31
37
32
38
* We can build a self contained user management in the accounts service and can adjust it to our requirements.
33
39
* 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).
34
40
35
-
### Negative Consequences<!-- optional -->
41
+
### Negative Consequences
36
42
37
43
* We need to spend time on implementing user management
Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020)<!-- optional -->
13
+
Technical Story: [Skip account-service by talking to CS3 user-api](https://github.com/owncloud/ocis/pull/1020)
8
14
9
15
## Context and Problem Statement
10
16
11
17
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.
12
18
13
-
## Decision Drivers<!-- optional -->
19
+
## Decision Drivers
14
20
15
21
* oCIS should be a single binary that can run out of the box without external dependencies like an LDAP server.
16
22
* Time: we want to build a release candidate asap.
@@ -55,20 +61,20 @@ Chosen option: "Move accounts functionality to GLAuth and name it accounts", by
55
61
- The current CS3 API for user management should be enriched with pagination, field mask and a query language as needed
56
62
- 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)
57
63
58
-
### Positive Consequences<!-- optional -->
64
+
### Positive Consequences
59
65
60
66
* The accounts service (which is our drop in LDAP solution) can be dropped. The CS3 userprovider service becomes the only service dealing with users.
61
67
* No sync
62
68
63
-
### Negative Consequences<!-- optional -->
69
+
### Negative Consequences
64
70
65
71
* 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.
66
72
67
-
## Pros and Cons of the Options<!-- optional -->
73
+
## Pros and Cons of the Options
68
74
69
75
### GLAuth wraps accounts service
70
76
71
-
Currently, the accounts service is the source of truth and we use it to implement user management.<!-- optional -->
77
+
Currently, the accounts service is the source of truth and we use it to implement user management.
72
78
73
79
* Good, because it solves the problem of storing and looking up an owncloud UUID for a user (and group)
74
80
* Good, because we can manage users out of the box
@@ -77,7 +83,7 @@ Currently, the accounts service is the source of truth and we use it to implemen
77
83
78
84
### Move accounts functionality to GLAuth and name it accounts
79
85
80
-
We should use an existing LDAP server and make GLAuth a drop in replacement for it.<!-- optional -->
86
+
We should use an existing LDAP server and make GLAuth a drop in replacement for it.
81
87
82
88
* Good, because we can use an existing user repository (an LDAP server), no need to sync or learn users.
83
89
* Good, because admins can rely on existing user management tools.
@@ -102,3 +108,6 @@ We should use an existing LDAP server and make GLAuth a drop in replacement for
102
108
* Good, because we can use the CS3 user provider with the existing LDAP / rest driver.
103
109
* Bad, because oCIS admins may not have the rights to manage role assignments. (But this is handled at a different department.)
104
110
* Bad, because oCIS admins may not have the rights to disable users if an external LDAP is used instead of the drop in GLAuth.
oCIS is documenting architecture decisions using [Markdown Architectural Decision Records](https://adr.github.io/madr/) (MADR), following [Documenting Architecture Decisions by Michael Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions).
12
+
13
+
{{< toc >}}
14
+
15
+
To manage the records we use [butonic/adr-tools](https://github.com/butonic/adr-tools), a fork of the original [npryce/adr-tools](https://github.com/npryce/adr-tools), based on [a pull request that should have added MADR support](https://github.com/npryce/adr-tools/pull/43). It also supports a YAML header that is used by our Hugo based doc generation
0 commit comments