Hi everyone!
We’re happy to finally start rolling out Single Sign On support in SelfPrivacy! Before we roll it out to everyone, we want to gather some feedback first on the pre-release version. This post will guide you through this process.
What is SSO?
Single Sign On is a feature that allows your users to login into different services on your SelfPrivacy server using a single account. And you, as an administrator, get the centralized user management.
We use Kanidm as an Identity Management server.
Which services support SSO?
Right now, the following services in SelfPrivacy support SSO:
- Nextcloud
- Forgejo
- Roundcube
Single Sign On will be turned off by default on existing servers, except for E-mail.
Because E-mail clients do not usually support SSO mechanisms, we provide a Self-Service Portal for your users, where they can manage their E-mail passwords. To not interrupt your current processes, we migrate an existing password to the new system as an E-mail password. It means, it can only be used to log in an E-mail client.
To use other services with SSO:
- You will need to enalbe SSO support in each service you wish. You can do it using the app, in service settings.
- Your users will have to set their credentials. To do this, they will need a password reset link that you can generate in SelfPrivacy app.
Further down in the post we will discuss the caveats related to turning on SSO in each service.
Requirements for testing
To test SSO you will need to use the latest nightly SelfPrivacy version, and also manually switch your server to sso
branch using SSH.
You can grab a nightly version of our app at our F-Droid repository: https://fdroid.selfprivacy.org/
To switch your server to sso
branch, SSH into it as root, and execute this one-liner:
cd /etc/nixos && sed -i 's/ref=flakes/ref=sso/g' sp-modules/flake.nix && nix flake update --override-input selfprivacy-nixos-config git+https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-config.git?ref=sso && nixos-rebuild switch --flake .#default
Explanation of the command
This one-liner chains several commands after each other:
cd /etc/nixos
switches you current working directory to/etc/nixos
, where the local SelfPrivacy Nix Flake is locatedsed -i 's/ref=flakes/ref=sso/g' sp-modules/flake.nix
will switch the branch of each SelfPrivacy Module you havenix flake update --override-input selfprivacy-nixos-config git+https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-config.git?ref=sso
will override your current SelfPrivacy configuration input with the one fromsso
branchnixos-rebuild switch --flake .#default
will start the system rebuild process that will apply all changes
It will take several minutes. Then, open your app and fix DNS records: there will be a new one for Kanidm.
After you switch to sso
branch, you will receive server upgrades from it, until we finish pre-release testing. After this, your server will automatically switch back to the stable branch.
SelfPrivacy Self-Service Portal
At api.
subdomain of your server, there will be a self-service portal for your users. Right now, it has the following functions:
- E-mail passwords management, with a quick setup button for Delta Chat.
- Ability to change the display name
- A list of available services
Effect on services
Your E-mail server will support both oAuth2 and plain logins. The existing user password will be migrated as an E-mail password, so your E-mail clients should continue working as usual. You will still need to use the full E-mail (with domain) as a username to log in.
Nextcloud
After you enable SSO:
- You can still use old accounts with the same login and passwords.
- If the SSO account has the same username as the account already on Nextcloud, they will be merged. You will be able to log in using both SSO and old username/password. In other words, SSO becomes a secondary login method for these accounts.
- If you grant SSO account admin rights, it will have admin rights in Nextcloud
- SSO users with usernames that didn’t exist in Nextcloud before, won’t have an option to set a password in Nextcloud. In other words, SSO will be the only possible login method for these accounts.
Forgejo
After you enable SSO:
- Forgejo will load all SSO users into its database
- It will be possible to log in ONLY using SSO
- Old accounts can still be accessed if you create a SSO user with the same username
- If you grant SSO account admin rights, it will have admin rights in Forgejo.
Roundcube
You will have to use SSO login instead of username and password.
Managing users
Now, when you create (or edit) a user, you will see two new inputs: group and explicit permissions.
Group determines implied permissions of a user, and there are three of them:
- Only Email: Only gives a user access to E-mail. All other permissions have to be given explicitly.
- Full User: User will have access to every service that has SSO enabled on your server. When you add a new service, all Full Users will get access automatically. If you need to give this user admin rights for a certain service, you can still do this with explicit permissions.
- Administrator: Will have access to every service, and if a service supports it, this user will also have admin rights. Generally, gives access to everything managed by SSO at this moment.
Explicit permissions override a group permission on a service-by-service level. Admin permission includes user access.
After you create an account for a user, they need to set credentials. It is something they should do themselves. Use the “Request password reset link” button to generate a link. A new screen will give you the options to copy link, share it or show a QR code of it.
Clicked by an accident? No worries. Credentials are not changed until a user visits a link. This link is only valid for an hour.
What to test
We need your feedback on the following topics (but not limited to them):
- Application UI to manage users
- Self-Service Portal
- E-mail passwords
- SSO integrations in Nextcloud, Forgejo and Roundcube
- Any crashes, issues or server rebuild failures