Clear Separation of User and Account (Account Management)

Since a user can have multiple accounts there should never be something depending on an account if it should indeed depend on the user.
But Neos does just that: f.e. the name of the user workspace is derived from the account identifier of the default authentication provider (Typo3BackendProvider). Therefore an account with this provider is necessary to correctly log in (see 'Invalid accounts' and the backend redirection service).

To successfully transform this mess, the account management has to be extended (or actually implemented into the user management) additionally.

How would you implement it? It would be great to have to be able to extend Neos in a way that you can implement an authentication where the user can login f.e. with either Facebook OAuth or Google OAuth (in this example explicitly not using the default auth provider) as the user likes.

I wouldn’t consider it a mess. Workspaces are a feature of Neos and internally Neos expects a user to have an account for the Backend Provider in order to access the backend. Therefore I think it is legit to use that account identifier for the personal workspace identifier.

But of course, if we can come up with a backwards-compatible solution which makes this connection clearer, I’m all open for that.

I think you’re mixing things up, and that’s exactly the same mixup that causes the problem @SoulCover is pointing to. The workspace is now account identifier based, which is wrong in 2 ways:

  1. The workspace belongs to the user, but we link it to an account while a user could have multiple accounts.
  2. The account identifier is used, which is not unique as the unique constraint is account identifier + authentication provider name

Probably it’s best to store the name of the workspace on the user model. We can do that in a BC way by a simple migration. And then generate the workspacename on first login of the user and make sure it’s unique. This would also enable the use of multiple authentication providers for Neos backend access.

Agree to this.

If i use multiple accounts i also would expect to have multiple workspaces. Otherwise i will end up with a personal workspace that has content or changes i have no permission for.

The identifier problem should be fixed indeed.

That has a contradiction into it :wink: So yo expect multiple workspaces for the same user if he has multiple ways (accounts) to log in? Because exactly that would lead to workspaces without permission… I would expect that, no matter if I log in with my google account, facebook, oauth provider or whatever: if the accounts are linked => same user (and thus the same workspace).

I thought about having an Editor and an Administrator Account. In that Situation i would prefer separate Workspaces. But your Scenario is valid aswell.

Both scenarios could be supported on the same time if one account could have multiple authenticationProviders.

That’s an interesting point. Having the same user with different accounts and those accounts having different roles is a bit of a problem in general…
@andi @bwaidelich Any ideas how to handle this scenario? Seems quite strange to me…

I never thought about that tbh, but sounds like an awesome feature. But it would require some kind of “role grouping” or so… I see a chance for introducing an extra “context” :wink:

atm the roles are linked to the account. This is probably the best solution for now as you can sync the roles if you want to have the roles linked to the user and don’t if you want them linked to each account separately (the modification interface would have to be changed accordingly).

I just came up with an example of users having different roles for different accounts: One account can only be used “on site” and has f.e. the admin role and the other, which can be used from elsewhere, has only the mod role.
There seem to be some other scenarios. I’m not sure if the roles shouldn’t be depending on context though…

It would not require role grouping but managing the authentication separate from the account. That would require neos-ui and flow-security changes but i think this can be done in a backwards compatible way.