Love the conversation this has kicked off, and I think there's a few good things to consider here:
The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.
A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.
That sounds like an important use-case indeed and goes into a whole field of more fine-grained control over what users can and cannot do. So far we have tried to not overcomplicate the access control settings, but we are open to small useful adjustments. Given that Cloudron has a special permissions group, the admins and then simply the rest of the other users, would it be sufficient for your use-case to have an admin setting to prevent non-admins from changing their own profile? And if so, what fields should be protected?
Thinking about it, if there were going to be a bigger, badder SSO solution "baked in" to the platform, keycloak (https://www.keycloak.org) may be the better tool to close some of that gap than Shibboleth for the job (OpenID Connect, OAuth 2.0, and SAML support built-in; similar flexibility on the backend). My main thought in the use case of SSO apps is that SSO as a platform component is, to date, a platform-internal feature, and I think there's a huge benefit to being able to essentially treat Cloudron as your authoritative directory / user store and leverage it for SSO with SaaS and other strictly off-host products.