Site-Admin-User Sync

[jospaas]

Hi There and a big thank you! Panopticon makes managing sites pretty easy!

When managing multiple sites, updates and backups are one of the biggest challenges that appears.
My problem: What about admin-accounts?
As a service provider we're managing multiple sites. On every site needs to be a super-user-account for every person from the service provider. We could also use a single one, but different persons should have different accounts.
The result: Every site has the same account (user and password), maybe MFA enabled.
For better security it would be great if there is a solution for managing the service-provider-super-users in one place, including 2FA.
It should be like an IDP for super users.
I know that there are multiple plugins that enables sso / user provisioning with IDPs. All of them are creating local users, wich could authenticate local only. After creation the user is not updated anymore. A generated password is set only once when user is created. But from a security perspective, passwords should be changed regulary.
A better way would be, if a provider has a centralised place and all users would be synced to the sites (including deletes or disabling).

When i was searching for it, i couldn't find a good solution for it.

Panopticon is already targetting people / providers who manging multiple sites. I know that there are several challenges and it's much work till it's implemented, but maybe this would be a nice feautre?
Maybe it's the wrong place, because remote-cli would be better to allow manageing sites-users.

What do you think about it? Do you know a better way for it?

[nikosdion]

Remote management of users is a massive security risk. For this reason, I am taking the stance that user managements is explicitly outside Panopticon's purview. In fact, I recommend against enabling the Web Services - Users plugin for security reasons.

JSON APIs are, by their nature, single-factor authentication: all you need is the token. This lowers the bar of an attack to subverting the token. Therefore, the JSON API should only offer as many features as necessary to do remote management, but not in a way that can subvert the security of the application it manages.

Note

This is why I have not implemented #346 yet. Allowing remote installation of extensions is equivalent to allowing arbitrary code execution. There is no way to make it safe unless Joomla implements a concept of signed extension packages. I had talked about that in J and Beyond 2017 in my Friend Or Foe presentation. It's not even a novel concept. At this point, it's been done at scale for decades.

Having a different Super User account on each of your client sites for each of your staff members is a bad idea. You put the security of your clients and the very existence of your business in the hands of your staff. All it takes is one disgruntled or careless staff member for all your client sites to be destroyed and your business evaporating.

On top of that, you have them change the passwords regularly which has been known for decades to actually promote less secure passwords and bad password storage practices. In fact, the current NIST advice is AGAINST changing passwords regularly exactly for this reason.

The correct way to handle it is to have one Super User account for your MSP per client site. Each one of these accounts should have its own, randomly generated password – ideally, a 128 character long one consisting of lowercase and uppercase letters, digits, and special characters. It should also have MFA enabled, ideally WebAuthn which cannot be exfiltrated by copying a fairly short key onto a piece of paper. All that stored in a centralised password manager, using one vault per client. Each staff member gets their own login to the password manager, and they are assigned access to the vaults for each client whose sites they are going to be managing. You can easily do that with 1Password, including the WebAuthn bit.

When you get a new client, you create one service account which is locked down tight. When the client decides to not renew their contract, you delete your service account in their sites, and delete their vault from your password manager.

When you get new staff, you create a new password manager account, and let them access whichever vaults they actually need. When that staff member is going away, you revoke their password manager account.