Access Control for User Account topics is broken

[jri]

Access Control for User Account topics does not work correct in DM 4.5-SNAPSHOT.

A User Account topic is supposed to be *editable* by the very user only, e.g. to change hers password. (And it is supposed to be *seen* by everybody. Is it??)

Currently in 4.5-SNAPSHOT the "admin" user can *not* edit hers own User Account (as it has no workspace assignment) but *can* edit all the User Accounts she creates (as they are assigned to the public "DeepaMehta" workspace by default!). Verkehrte Welt!

My intuition is: each user requires a private workspace. (At the moment this is not a strict requirement.) So, each time DM creates a User Account it is supposed to create a private workspace as well and assign the User Account topic to that.

Furthermore a user must be prohibited to delete hers own private workspace (otherwise she would loose the opportunity to change hers password). On the other hand, a user should be free to create further private workspaces on their demand. Should she?? In this case the concept of a "distinguished private workspace" must be introduced. The distinguished private workspace would be the one which can't be deleted. (In contrast hers other private workspaces can.)

... oh boy, complexity rises ...
What do you think?

[JuergeN]

Hi Jörg, I agree to your thoughts and I think it all sounds very logical to me.

I think that creating a private workspace for each user account by default makes a lot of sense. (Same as in most linux distros, where users get their own home directory by default.) I do not know, if you need to implement extra protection for that workspace, because, as discussed earlier, a workspace should only be deleted if it has no further assignment, anyways. (In Linux users _can_ delete their own home directory, if they really want to, but maybe you want to prohibit that ...)

As I understood, the username must be visible to other users, because they must be able to add them as members of other workspaces. So the username would remain as a topic inside the default DeepaMehta workspace (Public). The password would remain in the user's distinguished private workspace (Private).

If you apply the same rule for the admin user, all should be fine again. So the admin user also gets her distinguished private workspace, where her password is stored. So then she should be able to change again. :)

[JuergeN]

And yes, users should still be able to create more private workspaces, if they want to. But I do not see any problems here.

[JuergeN]

Wording question: How would you label the distinguished private workspace?

a) distinguished workspace
b) my (private) workspace
c) ${username}'s workspace
d) your ideas here ...

[JuergeN]

Replying to JuergeN:

Wording question: How would you label the distinguished private workspace?

a) distinguished workspace
b) my (private) workspace
c) ${username}'s workspace
d) your ideas here ...

... or may be just the same as the username.

[Malte]

I would rather see "User Account" editing by logged in usernames as one of more special cases which are not related to Workspace assignments, since the definition is clear:

A User Account topic is supposed to be *editable* by the very user only, e.g. to change hers password.

while,

(it is supposed to be *seen* by everybody. Is it??)

Yes, some *child-topics* of a "User account" (e.g. "E Mail Address" or "Display name" of the dm4-eduzen-identity plugin) may be available to read by everbody and thus be part of another workspace (which allows for such).

There were more special cases we discussed in our last meeting on this (but maybe we didn't finalize them enough):

• The "admin" should be the member of a new "System"-Workspace created per default by DM and this would solve the issue described above ("admin" cannot change its own password).

Additionally, in our last face-to-face discussion we (representing end-users and plugin developers) reported extensively of cases for which some special (system) rights needs to be pulled in for either (a) the username "admin" or even better (b) for (potential) members of the "System"-Workspace:

Such special rights would include:

• Editing the password of any other "User Account" topic in the system
• Editing a plugins options which are available as topics and should be assigned to the "System" workspace. Just to name a few which already exist and would profit of such a general level of permissions:
  • WEB API keys of connected third party systems (twitter app),
  • importer settings (wikdiata dump options),
  • systems default mail sender configuration (dm4-mail),
  • in some cases changing type definitions, too (e.g. configuring a taxonomy for certain types, like often with dm4-tags)
  • .. juergen, name it.

As i see it, the new ACL model for workspace and a new system workspace (of type private? for "admin") would conceptual cover all this and would be one pretty simple move.

To pull in extra rights for users of the "System"-Workspace would be more neat and flexible (than just giving extra rights to username "admin") because plugins could assign custom topic types to this workspace! This would

• enable/allow for at least one (admin) or potentially more end-users within a system configuration of the system/plugin
• provide a simple *convention* for plugins to assign their system related topics (topic types reporting on system usage, types allowing plugin configuration..).

Imho, introducing a "System" workspace now has the potential to merge some long spoken need for making (build, compiled and released) plugins system options in database (a) by end-users (b) and in a well defined manner (convention) with this very development sprint on collaboration within and permissions within one DM4 instance.

Please tell me where I am wrong.
Overall, it feels great to see that such workspace-model is going to happen :)

[Malte]

The first line in my response states clearly: No additional private workspace for users but ... (let just the owner of this topic) edit it (disregarding its workspace assigments).

And sorry for my very hard to read comment but I am in the hope two points got through:

• No mandatory private worksace for changing, e.g. the password should be required and thus there should not be a problem with "prohiting" users from deleting their private workspace.
• Admin needs a "System" Workspace (of type "private" or one collaboration level higher.

Cheers!

[Malte]

Point three was:

Replying to jri:

A User Account topic is supposed to be *editable* by the very user only, e.g. to change hers password. (And it is supposed to be *seen* by everybody. Is it??)

Yes, with a "one workspace per topic" rule in place it should be possible that child-topics are assigned to a different workspace than their parents.

[Malte]

So, after having the thoughts sink in a bit, my proposal for realizing this would be:

• "Owner"-ship of a topic grants WRITE permission over the Workspace ACLs permissions in which a topic lives, analogous to
• "admin" who anyway needs the permission to edit _any_ "User Account" (regardless in which Workspace that topic lives) and thus it seems even advantageous
• to implement distribution of such an administrative permission not for one user identified by the username "admin" but simply all users identified by "a membership to workspace "System"
• "admin" becomes the only default member of the new "System" workspace (private) and is the only one who can grant or detract membership to other users for this special "Sytems" workspace

This way, no introduction of un-deletable private workspaces and further benefit and convenience for everyone involved, mainly through a properly introduced context ("System" workspace) in which system-related topics (as described above) can live in a well defined scope and get edited by a well defined group of users.

Hope this helps & if not, it was worth a try.

[jri]

Thank you all for input!

After considering all things we come up with this concept:

• With DM 4.5 topics/associations will NOT have an individual owner anymore. Only workspaces have. Topics/associations get their ownership solely by their workspace assignments.
• Each topic/association/type/topicmap is assigned to exactly one workspace. (Only workspaces have no workspace assignment themselves.)
• Access control is primarily governed by workspace ownership and the 5 workspace sharing modes. Privacy is realized by the "Private" mode. Group/Public? access is possible through the other 4 modes.
• We don't pursue a kind of "superuser" who could e.g. edit all accounts.
• If a user forgets hers password an "I forgot my password" workflow (based on email-address) will be established.
• The "admin" user is not special in any regard. It's just the default user which comes with the DM Standard Distro. Hers "power" is dictated by hers memberships, just like for any other user.
• Each user (and thus the "admin" user) will get a private workspace by default.
• The different parts of a composite topic are assignable to different workspaces. #752 is relevant here.
• The "User Account" and "Password" topics will be assigned to the user's private workspace. The "Username" topic will be assigned to a public workspace.
• Dedicated application logic in the Access Control module will prohibit Username changes.
• A workspace which still has assignments can't be deleted. (Thus deleting the private workspace which holds the user's password is only possible when deleting the password as well. This would represent the "Delete My Account" case.)
• A user can create a Membership (between a username and a workspace) only if both is granted: READ permission to the Username, and WRITE permission to the workspace.
• A special "authority" (which is not represented by any user) is the Core itself. The Core is the only entity which have direct access to the DB and thus can bypass the access control system. Bypassing is required to resolve the vicious circle as enforcing the access control rules involves DB access in itself (e.g. checking ownership and memberships).
• Special cases and extensions to the primary rules are supposed to be realized by the applications themselves.

So far for the current concept. I'm confident that this will provide us a solid base for a whole variety of applications.

[jri]

I'm not yet happy with this part:

Replying to jri:

• [...] The "Username" topic will be assigned to a public workspace.
• Dedicated application logic in the Access Control module will prohibit Username changes.

The the crux is: at one hand the Username must be assigned to a public workspace in order to be visible to everyone. At the other hand this implies that all members of that workspace are able to change all usernames! That's why I came up with the 2nd point about dedicated application logic in the Access Control module. However, this sounds odd to me.

One solution to avoid dedicated application logic in the Access Control module would be the introduction of a 6th workspace sharing mode: Public Private.

Sharing Mode	Owner	Member	Everyone
Public Private	write	read	read

(compare with the table in ticket:592#comment:1)

A Public Private workspace is public in the sense everybody can read but private in the sense only the owner can write. Here the Member role is pointless: becoming a member would make no difference (just like with a Common workspace.)

The Username would be assigned to a Public Private workspace then.
Besides its Private workspace each user would get a Public Private by default then.

What do you think?

[jri]

Replying to jri:

I'm not yet happy with this part:

Replying to jri:

• [...] The "Username" topic will be assigned to a public workspace.
• Dedicated application logic in the Access Control module will prohibit Username changes.

After further discussion we came up with this concept:

• A 6th Sharing Mode ("Public Private") will not be introduced.
• Instead the DM Standard Distro comes with a public workspace "System", with "admin" being the only member.
• Username topics will be assigned to workspace "System" by default.

[Jörg Richter <jri@…>]

In cf422327f34d829e7b7534ce8782263e7599c5f7/deepamehta:

Add "New User Account" dialog (#751).

Thus a username and a password is already known at the time when a User Account is created.

See #751.

[Jörg Richter <jri@…>]

In 2be02cf3a617a016349351cd7316030acbcb8d0e/deepamehta:

AccsCtrl?: add createUserAccount() method (#751).

The Access Control service has a new method:

Topic createUserAccount(Credentials cred)

REST API:

POST /accesscontrol/user_account

{"username": username, "password": password}

BREAKING CHANGE

One client-side REST client methods renamed:

dm4c.rest.join_workspace -> dm4c.restc.create_membership

See #751.

[Jörg Richter <jri@…>]

In 936bfaafc22418a8c0ce08a7b7b2fadd0f3f7207/deepamehta:

User account workspace assignment (#751).

The "System" workspace is introduced.

When creating an User Account:

• a private workspace is created for the user.
• the User Account and the Password are assigned to the user's private workspace.
• the Username is assigned to the "System" workspace.

NOTE: login is broken with this commit.
Checking the credentials must perform with special privilegs (inside the Core).

BREAKING CHANGES

Workspaces API:

1 dropped method:

Topic getDefaultWorkspace()

1 new method:

Topic getWorkspace(String uri)

Returns a workspace by URI.
If no workspace exists for the given URI a runtime exception is thrown.

3 new constants in WorkspacesService interface:

String DEEPAMEHTA_WORKSPACE_NAME
String DEEPAMEHTA_WORKSPACE_URI
SharingMode DEEPAMEHTA_WORKSPACE_SHARING_MODE

To get the "DeepaMehta" workspace:

Topic workspace = wsService.getWorkspace(WorkspacesService.DEEPAMEHTA_WORKSPACE_URI)

See #751.

[Jörg Richter <jri@…>]

In a2e83e104a33eb114a2894b81e1c23696ea1e75e/deepamehta:

Fix credential check (#751).

Checking the credentials performs with special privilegs (inside the Core).

Set ownership for private workspaces and for the "System" workspace.

NOTE: creating user accounts does not yet work.

Access Control API:

1 new method in interface de.deepamehta.core.service.accesscontrol.AccessControl:

boolean checkCredentials(Credentials cred)

BREAKING CHANGES

Access Control API:

1 renamed method:

Topic getUsername(String username) -> Topic getUsernameTopic(String username)

Class Credentials moved package:

de.deepamehta.plugins.accesscontrol.model -> de.deepamehta.core.service.accesscontrol

See #751.

[Jörg Richter <jri@…>]

In 7f25d2ee1fa64b7a79b71c66a5146565d94e182f/deepamehta:

Fix creating a user account (#751).

The original problem of User Account Management is now solved.

• The admin can edit hers user account (and see no other user accounts).
• The same applies for all user accounts created interactively.
• After creating a user account its Username topic (which is public) is revealed in the topicmap, ready for being associated with workspaces (via Membership).

Issues:

• The user who creates a user account becomes (by default) a member of the new user's private workspace. While annoying this is not a pressing problem as memberships of private workspaces are ignored.

Changes in Access Control API:

The topic returned by the createUserAccount() call is the account's Username topic (not the User Account topic).
Note: the User Account topic is private and thus not accessible by the user who made the createUserAccount() call.

Topic createUserAccount(Credentials cred)

1 new method in interface de.deepamehta.core.service.accesscontrol.AccessControl:

void assignToWorkspace(DeepaMehtaObject object, long workspaceId)

It creates a workspace assignment while bypassing access control.

See #751.

[Jörg Richter <jri@…>]

In 7207e866e444a28bf7990b70b6739c0312f4e115/deepamehta:

Fix memberships (#751).

The user who creates an User Account does *not* become a member of the new user's private workspace.

Underlaying general change:
When a workspace is created the current user does *not* become a member of that workspace anymore. This is not necessary as the current user already becomes the *owner* of that workspace. (A membership is pointless when I'm the owner anyway.)
Note: creating an User Account is a special case in this context. Here, of course, the *new* user becomes the owner of hers private workspace (not the user who creates the account, and thus the private workspace).

See #751.

[jri]

Replying to jri:

After further discussion we came up with this concept:

• [...] the DM Standard Distro comes with a public workspace "System", with "admin" being the only member.
• Username topics will be assigned to workspace "System" by default.

Now, when the System workspace is implemented, I like to question its purpose. The original problem was how can we make the Username topics public? Why not just assigning them to the DeepaMehta workspace then? It is a public workspace just like the System workspace. When it doesn't help with the original problem I would like to drop the System workspace (at the moment) as it clutters the Workspace menu (as seen by every logged in user).

Another aspect of the original problem which is not yet solved: JuergeN want's to prohibit users who are not logged in be able to see/retrieve all Usernames. How can we solve that? From my point of view we can't solve that with the current ACL concept (ticket:592#comment:1) as we don't differentiate the Everyone and Authenticated roles. I see a pressing need for rethinking our ACL concept as I don't want do quick hacks here.

Please help!

How can the usernames made be readable only to authenticated users?
Are we supposed to extend our ACL concept by kind of a Authenticated role?

Your input is appreciated very much.

[Jörg Richter <jri@…>]

In a009bc20cff691d19f49d26296dbd1fbb2524ec0/deepamehta:

Fix admin memberships (#751).

The admin user has no membership for the DeepaMehta workspace anymore.
This is not necessary as she is already the *owner* of that workspace.

See #751.

[JuergeN]

Hi Jörg, I think the answer is close to what you are questioning here already. I would suggest that the system workspace is exactly what you are describing. It is the one workspace, that people can only see when they are logged in, even when it is a public workspace. I think we cannot addopt all the general logic to such a special topic like user and account management and from my guts I feel that a System workspace is something we do need. For me the DeepaMehta workspace is the _content_ container with the default topic types for PIM. But the System workspace is a special workspace for user and account management.

[jri]

I understand your point. You say that Usernames and account management are special and our usual access control rules can't apply here as access control is governed by these very user accounts. A vicious cycle occurs that must be resolved *outside* the rule mechanism. Yes, that's true for e.g. for checking login credentials or creating user accounts. Here the system needs to perform operations who are normally not allowed. These can be seen as "privileged operations" as they must bypass the access control system.

However, "Read a Username" is not that kind of operation. Access control must *not* be bypassed, just the contrary: access control must be in effect and must be even *more* restricted. Your proposal is doing that by implementing proprietary exceptional rules to the access control system.

From my point of view the original problem -- making all usernames readable for all logged in users -- has nothing to do with vicious cycles and privileged operations but with the lack of an "Authenticated" role in our access control concept. My feeling is that such a role is of general need for other applications as well. That's why I'm hesitating to "hack in" these exceptional rules. Rather I would like to think about whether we're supposed to extend our access control concept with an "Authenticated" role.

However, as a more pragmatic solution, we can go the way you propose and hardcode an exceptional rule which involves the System workspace.

[JuergeN]

Good. :)

[jri]

Please help me with another puzzle :-)
That is memberships.

Assume this situation: the admin invites 2 users to some workspace. That is the admin creates 2 memberships. A crucial question is:

To which workspace are memberships supposed to be assigned?

Let's investigate some options:

• By default the memberships are assigned to the workspace the admin has selected when creating them. (Sounds pretty arbitrary, right?) Let's say the memberships are assigned to the public DeepaMehta workspace. As a consequence every DeepaMehta member would be now allowed to delete the memberships! That is not was is intended, right?

Who is supposed to delete a membership?

• The memberships could be assigned to the System workspace (just like the Username topics). In this case no arbitrary user can delete the memberships but only the admin users can. But a user is supposed to be able to delete its memberships on hers own will, right?

• This indicates a membership should be assigned to the Private Workspace of the very user involved in that membership. This means only the particular user can delete the membership. However this leads to an odd situation usability-wise: let's look at the admin how she creates a membership. First she creates an association and then retypes it to Membership. Let's say the system then (re)assigns the membership to the respective user's private workspace. At this moment the admin has no permission anymore to see the membership -- it is supposed to vanish from the topicmap. (A topicmap never shows things the current user is not allowed to see.) To the admin it looks like: I retyped an association and now it is gone! That's confusing.

An accompanying question is:

Who is supposed to see the memberships of a user/a workspace?

Puh, what a tricky stuff!

One possible approach would be to abolish Direct Manipulation of the Graph for certain tasks and resort to dedicated UIs, e.g. a dialog to manage a user's/a workspace's memberships, and/or dedicated "Join" and "Leave" commands.

To me it seems that Direct Manipulation of the Graph has its intrinsic limits. Although this is one signature feature of DM it is not suitable for every situation. I wish it would and we could find a solution.

[Jörg Richter <jri@…>]

In 2909b036a7d9c347c22e477b955f4ec76be0898f/deepamehta:

Enforce special rule for System workspace (#751).

Although the System workspace is a public workspace its content (in particular the Username topics) are readable only for logged in users.

This is realized by a harcoded rule in the access control system.

See #751.

[jri]

Replying to jri:

[...] To which workspace are memberships supposed to be assigned?
[...] Who is supposed to delete a membership?
[...] Who is supposed to see the memberships of a user/a workspace?

A pragmatic solution to the problem would be:

• We always assign Memberships to the System workspace. This makes them readable by logged users (provided the respective workspace is readable), and deletable by administrators.
• We hardcode a 2nd special rule in the access control system: A Membership is writable to the very user who is involved in that membership. This allows users to leave workspaces on her own will.

Notes:

• The mentioned usability oddity would not occur as the administrator (who creates a membership) still has READ permission to the membership.
• Memberships of confidential and collaborative workspaces would be visible only to workspace members. Memberships of private workspaces would not be visible to anybody else. I think all this is pretty intuitive and useful. (All this comes from our general association visibility rule.)

What do you think?

[JuergeN]

I am not sure if I already understood all aspects here, but I would suggest to simply assign the membership association to the very workspace that it belongs to. If a user becomes member of workspace XYZ, the memberOf association is assigned to that workspace (XYZ). I think it is crucial that all users can create memberships and delete their own memberships if they have write permission to a specific workspace. I also think it is important that we provide some order here and that I can find the membership association in the workspace it belongs to. What do you think about it ...

[jri]

Replying to JuergeN:

[...] I would suggest to simply assign the membership association to the very workspace that it belongs to.

That would mean that a member of a public (or collaborative) workspace could delete the Membership associations of all the other members. E.g. you and me are member of a public workspace. I delete your membership. That is not what we want I think.

My suggested solution remains comment:25

[JuergeN]

Replying to jri:

Replying to JuergeN:

[...] I would suggest to simply assign the membership association to the very workspace that it belongs to.

That would mean that a member of a public (or collaborative) workspace could delete the Membership associations of all the other members. E.g. you and me are member of a public workspace. I delete your membership. That is not what we want I think.

My suggested solution remains comment:25

Yes, I am aware of the consequence. But actually I would like to enforce it. In my understanding all people with write permission to a workspace are collaborating on the same level (equal). They might as well delete all the content, which is possibly worse than deleting a membership. Maybe you can agree? Otherwise, we could try to discuss this a bit more in detail on the phone later this afternoon ...

[jri]

Replying to JuergeN:

Yes, I am aware of the consequence. But actually I would like to enforce it. In my understanding all people with write permission to a workspace are collaborating on the same level (equal). They might as well delete all the content, which is possibly worse than deleting a membership. Maybe you can agree?

I see, you regard the Memberships quasi as workspace content.
OK, let's do it this way!

[Jörg Richter <jri@…>]

In 881c7fc7126f42536677fb6fa3319c73a1763b66/deepamehta:

Only System members can create accounts (#751).

Workspaces API

The Topic getWorkspace(String uri) service call is RESTful:

GET /workspace/{uri}

The response is the workspace topic with the given URI.

1 new client-side method:

get_workspace(uri, include_childs)

Call it via dm4c.get_plugin("de.deepamehta.workspaces").get_workspace(...)

REST-client API

1 new method:

dm4c.restc.get_topics_by_value(key, value, include_childs)

The client-side counterpart of the List<Topic> getTopics(String key, SimpleValue value) core service call.

See #751.

[Jörg Richter <jri@…>]

In 410e7946063ab6183622f54f3f2c3ad619a6fcd7/deepamehta:

Fix "New User Account" command (#751).

The Webclient starts up properly.

See #751.

[Jörg Richter <jri@…>]

In 6bd69920316e3f43387e1236eec72368ab4d3ac7/deepamehta:

Assign Membership to referring workspace (#751).

When an association is retyped into Membership it is re-assigned to the very workspace the Membership refers to.

That means Memberships are editable/deletable by all workspace members.

Core API

1 new method in Association:

Topic getTopicByType(String topicTypeUri)

Returns the association's topic which has the given type.
If there is no such topic, null is returned.
If there are 2 such topics an exception is thrown

BREAKING CHANGE

Core API

1 dropped method in Association:

List<Topic> getTopics(String roleTypeUri)

See #751.