Partial User Management (Group membership only)

[rettichschnidi]

I would like to use Corporal to manage the creation of certain communities and their members on my server.

However, I do not want to manage anything else regarding the user, like the users password (authType/authCredential), avatarUri, displayName, joinedRoomIds.

I imagine a configuration like this:

{
	"schemaVersion": 1,

	"flags": {
		"allowCustomUserDisplayNames": true,
		"allowCustomUserAvatars": true
	},

	"managedRoomIds": [
		"!roomA:example.com",
		"!roomB:example.com",
	],

	"managedCommunityIds": [
		"+a:example.com",
		"+b:example.com"
	],

	"users": [
		{
			"id": "@john:example.com",
			"joinedCommunityIds": ["+a:example.com"],
		},
		{
			"id": "@peter:example.com",
			"joinedCommunityIds": ["+b:example.com"],
		},
		{
			"id": "@george:example.com",
			"joinedCommunityIds": ["+a:example.com", "+b:example.com"],
		}
	]
}

Is this possible?

[spantaleev]

Talking about passwords, someone brought it up lately.

We were discussing some "authType": "passthrough" feature, which could pass login requests to Synapse, instead of handling them inside Corporal.

Problem is, when a user doesn't exist, it's Corporal that creates the user. And it currently creates it in Synapse with some long, random, unguessable password. How are users expected to authenticate when their accounts have been created by Corporal with such a password?

If you can ensure that users are created by yourself (and not by Corporal) and assigned a password manually, then I guess an empty authType (or authType = "passthrough" feature) might be somehow feasible.

---

As for display names and avatars, it seems like you can leave them empty even now, so long as you use these flags:

"flags": {
	"allowCustomUserDisplayNames": true,
	"allowCustomUserAvatars": true
}

---

About room ids, if you don't define a certain room as managed (that is, if you don't put it in managedRoomIds), then it can exists by itself and Corporal will not enforce membership for it (joinedRoomIds will not matter).

Users can be part of any unmanaged room. Corporal only enforces memberships (or lack of membership) for managed rooms.

---

If you do all that, I'm not sure why you'd bother with Corporal though. It seems like you want Corporal to:

• NOT create users
• NOT handle authentication
• NOT handle room membership
• NOT enforce avatars / names

.. but only to enforce community membership.

It doesn't seem very useful to create such a setup, but I guess it might be possible to get it working. Most things should work even now. You probably only need the authType = "passthrough" option and to ensure all your users are created beforehand (and not by Corporal).

It should be noted that Groups/Communities is some experimental Synapse feature which doesn't work very well (there's quite a few bugs with it) and which would be getting redone in the future. It's uncertain what would happen and how Corporal would follow. I'm guessing that we'd like to still keep supporting it, but you never know..

[Medien-Treibhaus]

In our scenario we would like to use Corporal to:

• create users
• NOT handle authentication
• handle room membership
• enforce names (and certain avatars)

If Corporal would create the user in Synapse with the auth credentials given in the policy (say a plain password for the user to be changed later) instead of a long, random, unguessable password, taking the credentials out of the policy after the creation of the users would make an authType = "passthrough" useful, since it would allow users to change their password and verify/delete sessions (probably related to #11), plus we could still manage all the other aspects (which are extremely useful) with Corporal.

[spantaleev]

I've implemented authType=passthrough. It's available in matrix-corporal v1.11.0.

By default:

• authCredential is used for the initial password
• users are not allowed to change the password on the homeserver (access to the /_matrix/client/r0/account/password API is blocked)

If you'd like users to be able to change their password (via the /_matrix/client/r0/account/password API), you should toggle an additional main policy flag ("allowCustomPassthroughUserPasswords": true).

You can find more details in our Passthrough User Authentication documentation.

[starcraft66]

It is unfortunate that it is not possible to use corporal's user policy management without having it create the users. I am using Synapse with SSO via OIDC with Keycloak. Users don't exist in synapse until their first SSO login and I don't need two different tools where my users are defined in. If I want to use corporal, all users for which I have set a policy will be auto-created and then when the real person signs in via OIDC for the first time, synapse will helpfully append a number to their username because the original user already exists and then my policy won't apply to the actual user's account.

I am just looking for a tool that can restrict room creation to everyone except a few select administrators. Perhaps using matrix-corporal is overkill for this? I won't be needing most of its features.
@spantaleev is this a use-case you would be interested in supporting?

[shukon]

synapse will helpfully append a number to their username because the original user already exists and then my policy won't apply to the actual user's account.

you can use the setting allow_existing_users: true in the OIDC-part of your homeserver.yaml to avoid it doing that. Still, there are other potential caveats and I have a similar usecase as you do.

I think the complexity is a lot higher if there is a check for user-existence before every action and impersonating users without enabled password support seems not possible.